This question already has answers here:
Conditional Variable vs Semaphore
(8 answers)
Closed 8 years ago.
Why should we use wait() and signal() operation in multithreading applications?
I'm relatively new to multithreading and somewhat understand mutual exclusion but I need a better understanding of how wait() and signal() come into the equation.
It seems I'm achieving thread safety by only using lock() and unlock(). Am I wrong?
Can someone give me an example of wait/signal being used and wait and signal not being used with lock/unlock? What are the benefits to using wait/signal over just lock/unlock?
Thanks.
I work with computational maths/science so my examples come from there.
If you were doing a reduce operation such as a dot product (need to sum many calculations) then lock and unlock are useful as the order of the sum does not matter and if it's free the thread should go for it.
If you were solving a PDE over time before you can take the next time step the previous time step needs to be completed, a lock/unlock wouldn't work as even if the data is free for modification the prerequisite calculations may not have been done, this is where you would use a wait/signal.
Cramer your answer gave me good hints but the answer on this page was exactly the explanation I needed.
Conditional Variable vs Semaphore
Related
This question already has answers here:
Check to see if a pthread mutex is locked or unlocked (After a thread has locked itself)
(3 answers)
Closed 3 years ago.
I want to find out if a pthread lock variable is locked or not.
One simple approach is to use a trylock as shown below
pthread_mutex_t lockVar;
if(pthread_mutex_trylock(&lockVar) == 0)
{
//lock was successful
pthread_mutex_unlock(&lockVar);
}
else
{
//someone else holds the lock
}
How do I do the same thing without obtaining a lock?
When you have multiple executions happening concurrently, there is no notion of "simultaneity". Events cannot be given a global order in time, except for when explicit synchronizations happen. There is no property that's observable from within the language that can observe any kind of ordering in general.
Specifically, the question "is that mutex over there locked" is meaningless. It has no answer upon which you can act. Whatever the fictitious answer is, the state of the mutex can change right after. There is nothing you can do with an answer like "yes, it's locked" (it might become unlocked at the same time), or "no, it's unlocked" (it may get locked before you get there).
The only thing you can do with a mutex is try to lock it. You either fail, and thus know that it was locked, or you succeed and thus know that it wasn't, and now you have the lock.
Regardless of what you want to do with the result, the way you're doing it right now is the only way. You cannot simply query whether a mutex is locked without locking it. If you want a synchronization primitive for which you can query the status without modifying it, POSIX semaphores would be a possibility. A binary semaphore can serve as a lock (although it lacks the concept of an owner, which may be a problem for you if you need recursive locking) and sem_getvalue can determine whether or not the semaphore is "locked" at a single moment in time.
As for whether the question you're asking is even meaningful, Kerrek has already told you it's usually not. Here are a few possible, minimally-useful pieces of information you could gather from negative or positive results:
Negative:
If you know the lock started out locked, and won't be locked again once it's unlocked, this tells you an operation has finished. Here, a trylock-and-unlock approach would prevent multiple threads from being able to do this, since it would break the "never locked again once it's unlocked" invariant.
May indicate that it's worth preparing data, without the lock held, that you could apply later via trylock/unlock held only for a brief interval once the data is prepared. But of course you have to prepare for the case where things have changed by the time you take the lock later.
Positive:
If you know that the lock will not be unlocked once it's taken until your thread performs a further action allowing the lock-holder to proceed, this gives you information that a lock-holder has arrived.
Maybe others...
But for the most part, "is the mutex locked?" is not a useful question.
I know I am supposed to use mutexes but the way I currently use pthreads it would overly complicate the program...
anyway I basically have a variable which I use to denote if a thread is currently performing work or not. in the main thread I run over it in a while loop the check what threads are no longer busy. Now obviously my thread can write to this same variable once it is done.
Is it allowed to read and write from the same variable from 2 different threads, if 1 thread is ONLY reading and 1 thread is ONLY writing. reading of an old version is not of much concern since it will just read the correct once on the next iteration.
so is it safe to do something like that?
In general, NO.
The following article explains why:
http://www.domaigne.com/blog/computing/mutex-and-memory-visibility/
Here is a list of API functions that act as memory barriers:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11
I'm implementing a boss/worker design pattern using pthreads on Linux. I want to have a boss thread that constantly checks for work, and if there is work, then wakes up a sleeping worker to do the work. My question is: what type of IPC synchronization/mechanism should I use to achieve the least latency between my boss thread handing off to my worker, and my worker waking up?
The easy solution is to use Pthread conditional variables and call pthread_cond_signal in the boss thread, and pthread_cond_wait in each of the worker threads, but I'm wondering
is there something faster that I can use to implement the blocking and signaling? For example, how would using pipes between the boss and worker threads fare?
how can I measure the performance of one type of IPC versus another? For example, I see benchmarks for pipe()'s and fork()'s, but nothing for using pipe()'s as an interthread communication.
Let me know if I can clarify anything in my questions!
EDIT
As an example of how I would use pipe()'s to implement blocking between my worker and boss threads, the worker thread would read() a pipe, and since it's empty would then block on that read call until the boss calls write() on it.
The glibc implementation of pthreads uses the low-level "futex" locks to implement pthread_cond_wait() / pthread_cond_signal(). Futexes were designed to be a fast synchronisation primitive, so these are likely to outperform pipes or similar methods (at the very least, using pipes requires copying a byte to and from kernel space that isn't needed for futexes).
If pthread_cond_wait() / pthread_cond_signal() map well onto your problem (and it sounds like they do), then the only way to outperform them is likely to be to implement something on futexes yourself (for example, you could eliminate the handling of thread cancellation if you do not use that).
It is probably worthwhile benchmarking your application - unless your work units are very small indeed, then the condition variable wakeup latency is unlikely to dominate.
What you should do first is being sure you need something faster. Since pthread signaling is implemented using futex, where futex stands for fast user space mutex, I don't think you can out perform them.
If you have waiting threads, by definition you will have to wake them up, and this round trip through the kernel will be the source of your unwanted latency.
But what you should do is really think about your problem :
if you constantly have work to do, then your worker thread is always busy. Work will be done when previous work is finished, and you don't care about the latency.
If what matters is the latency between the boss detecting an event and the worker starting to work, then why do you use a boss -> worker pattern ?
My advice would be to look for a faster thing when you really need it, at this time you will probably have a much mre detailed question to ask. Maybe I am wrong, but it looks like you are trying to optimize preemptively, which as you perhaps know is the root of all evil. Of course, bad design can lead to massive rework, but here you are dealing with a very small detail of your real design decision which is using a boss / worker pattern.
Implement your design with pthread_signal, or perhaps semp_post() / sem_wait(), and then look where your latency really is, and if it is really a problem.
I would guess signal and wait would be the best. Most OS recognize threads and can have them just idle until the interrupt comes. With pipes the worker would have to keep waking up and checking the pipe for output. The best testing I've found for efficiency has usually been using the unix command to get the running time from start to finish(assuming the program isn't meant to keep running in the background), set up a script to do it a few times and compare.
Is there something equivalent to SIGSTOP and SICONT for threads? Am using pthreads.
Thanks
An edit:
I am implementing a crude form of file access syncronization among threads. So if a file is already opened by a thread, and another thread wants to open it again, I need to halt or pause the second thread at that point of its execution. When the first thread has completed its work it will check what other threads wanted to use a file it released and "wake" them up. The second thread then resumes execution from exactly that point. I use my own book keeping datastructures.
I'm going to tell you how to do things instead of answering the question. (Look up the "X Y problem".)
You are trying to prevent two threads from accessing the same file at the same time. In other words, access is MUTually EXclusive. A "mutex" is designed to do this. In general, it is easier to find help if you search for what you are trying to do (prevent two threads from accessing the same resource simultaneously) rather than searching for how you want to do it (make one thread wait for the other).
Edit: It sounds like you actually want many readers but one writer. This is probably the second most common synchronization problem (after the "producer-consumer" problem). Use a pthread_rwlock: readers call pthread_rdlock and writers call pthread_wrlock.
If you're doing something this sophisticated, you really should start reading the relevant literature. If you think you can do multithreaded programming some serious reading, you are much smarter than me and you don't need my help. I recommend "The Little Book of Semaphores" which is a free download (source). It's not about pthreads, but it's good stuff. The readers-writers problem you are asking about is found under §4.2 in the chapter "Classical Synchronization Problems" (heck, this problem is even mentioned in the blurb).
Multithreaded programing is HARD with capital letters and a bold font.
Well, there is pthread_kill.
But you almost certainly do not want to do this. What if the other thread holds (e.g.) a mutex for the heap, and you try to call new while it is stopped?
Since you do not know what the runtime is doing with mutexes, there is no way to avoid this kind of problem in general unless you completely avoid the standard library.
[edit]
Actually, come to think of it, I am not sure what happens if you target a specific thread with SIGSTOP, since that signal usually affects the whole process.
So to update my answer, I do not believe there is any standard mechanism for suspending a thread asynchronously... And for the reason mentioned above, I do not think you want one.
Depending on your application, Pthreads supports what can be considered more refined mechanisms, such as http://www.unix.com/man-page/all/3t/pthread_suspend/ and Mutex mechnisms
I’m buried in multithreading / parallelism documents, trying to figure out how to implement a threading implementation in a programming language I’ve been designing.
I’m trying to map a mental model to the pthreads.h library, but I’m having trouble with one thing: I need my interpreter instances to continue to exist after they complete interpretation of a routine (the language’s closure/function data type), because I want to later assign other routines to them for interpretation, thus saving me the thread and interpreter setup/teardown time.
This would be fine, except that pthread_join(3) requires that I call pthread_exit(3) to ‘unblock’ the original thread. How can I block the original thread (when it needs the result of executing the routine), and then unblock it when interpretation of the child routine is complete?
Use a pthread_cond_t; wait on it on one thread and signal or broadcast it in the other.
Sounds like you actually want an implementation of the Thread Pool Pattern. It makes for a fairly simple conceptual model, without repeated thread creation & tear down costs. Some OS's directly support it, on others it should be reasonably simple to implement using a queue and a semaphore.