Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
In a multi-threaded application, mutex::lock is used to prevent two threads accessing the same memory location at the same time. In my application, I do not use multiple threads but I have a callback function that writes to a vector and a loop in the main function, that reads it. Sometimes, I get this error:
Vector iterator + offset out of range
After checking the vector in debugging, all seems to be fine: the number of elements is right and none of the elements in invalid. Is there a similar possibility for callback functions?
No, there isn't. Mutexes are irrelevant for this case. Your out-of-range exception has nothing to do with concurrent access; it's just a logical error in your code. Find and fix that error, using your debugger.
If you don't have any concurrent calls to your callback function, there's no need for a std::mutex.
Is there a similar possibility for callback functions?
No, a callback function is called in sequential order, if there aren't any concurrent threads.
If you have out of range errors, use the debugger and check the index values used to access the vector elements.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have two processes of the same program, possibly running on two different machines.
I'd like the process P2 to receive a function pointer from process P1 via socket.
Is is possible? Is it a good practice?
EDIT: more interesting would be to send the code of the function too, but I'm skeptic about this. Would it be possible?
You can send a function pointer from one process to another, the same way you can send a pointer to some other object.
The problem is that the pointer may not actually point to the function as it exists in the target process. Especially if the OS is protecting itself with things like ASLR.
You could also send the code across, provided you had some way of figuring out where it ended, and that it was position independent code, and that your environment allowed you to write arbitrary data to memory and then call it.
But, to be honest, there are better ways to achieve what you seem to want, such as the use of RPC (remote procedure calls), in a more portable manner.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Can anyone tell me how to create more then one thread at a time
is there any such ?
like:
pthread_create (thread, attr, start_routine, arg)
should give me more than one thread at a time.
Your actual question seems to be more like "How can I make sure my tests exercise a potential race condition by calling the same function at the exact same time?"
The answer is, you sort of can't. Imagine your test runs on a single-processor machine. There's no way for the function to be called twice at the same time (but it could partially execute once then start again in the other thread).
Think about other ways to test for race conditions. At the more formal end of the spectrum, you can use tools like Spin and Promela to verify such things, but it's a lot more involved than spawning two threads in a unit test. For more, see here: http://lwn.net/Articles/243851/
A less formal way is to call your function in some way where it will sleep in its middle when the first thread calls it. Then you're very likely to see execution continue with the second call while the first one is suspended. But be mindful of wasting time on this approach, because it mostly validates that you've written the test correctly, and may not prove anything much about the thread safety of your code in practice.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I need to implement default behavior of exit call. I don't know what should I do and what is the most suitable way to do this. I have read that it should close file descriptors and something else.
Should I close default streams (stdout,err and in) ?
How to exit from nested functions calls ? Using goto is bad practice, what is the best way to break out ?
Thanks.
Do all of the things listed in exit(3), then invoke the _exit(2) system call. Alternatively, use longjmp(3) to jump back up to the main() function, then return from it. This invokes the same behavior as calling exit(3), and is just as dependent on the C runtime, so if exit(3) is unavailable for some reason, returning from main() will probably not work correctly either.
Unfortunately, AFAIK there is no portable way to enumerate all of the functions which may have been registered with atexit(3) and on_exit(3), so you'll have to keep track of those manually (i.e. every time you call atexit(3) or on_exit(3), append the function pointer to a list). Flushing stdio(3) is 3 straightforward fflush(3) calls.
You do not need to close any streams or file descriptors; the OS should do that automatically (the OS must not leak streams and fd's, so it is responsible for cleaning them up).
NB: longjmp() is almost always wrong under C++; throw an exception instead. It generally should only be used under straight C.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have two threads sharing a variable, but neither of them writes to that variable. I do understand that when two threads are dynamically reading or writing the variable, you do need a mutex. However, since, I am only reading the shared variable from either threads, do I still need to use a mutex?
P.S. Mine is a C++ program and I am using std::mutex.
If the variable is guaranteed not to be changed, then the reads don't need a mutex.
But if:
It's possible that the variable is written (by any thread) at the same time your threads are trying to read it
And, reads / writes are not atomic
Then you do need to synchronize.
As long as they are only reading from the variable, and the variable can be written/read with one store/read word operation then you don't.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
In my project I have a lot of MATLAB functions. For each function I call Initialize function, when the application starts. I tried to call this functions using parallel_invoke. I tried it several times and allways it takes more time, that code without this. Can somebody explain this ?
Is there is something specific in MATLAB or Initialize functions ?
The Matlab Runtime only has a single interpreter thread, so calling Matlab functions in parallel does not gain you anything: when the first function A is called, the MCR acquires a lock and only releases it when that function exits. Calling another function B during that period results in trying to acquire the lock, which then obviously just blocks until A finishes. The reason you see it taking up more time is probably due to the overhead of the locking/parallel_invoke.
I'm not sure what you mean with for each function I call Initialize function: unless you are using multiple Matlab dlls (which will afaik be less performant than having a single dll) you only need to call it's Initalize/Terminate once.