Re: [gentoo-user] OT: pthreads condition variable/mutex question
2014-08-13 12:21 GMT-05:00 Grant Edwards grant.b.edwa...@gmail.com: This is not Gentoo specific, and while I'm doing my prototyping and development on a Gentoo system, the eventual target is not going to be running Gentoo -- so feel free to ignore this thread or throw things at me. I'm trying to figure out how to synchronize threads which may be in different processes. Basically, I want thread A to be able to wake up any number of other threads B, C, D, ... who are all blocking until A says go (and who may or may not be in other processes). Other (mostly embedded) OSes I've used had some sort of event flag API that did exactly what I'm looking for, but I can't seem to find such a thing in pthreads. A condition variable in shared memory is the closest thing I have found, and my test applications are working OK (so far). But, I'm unclear on the purpose of the mutex whose address you pass to pthread_cond_wait(). Is it to prevent race conditions when manipulating the condition variable's internal state? I don't see how that can be the case, since the signal/broadcast call would have to be aware of it and it isn't. The mutex appears to be there to serialize access to some user-defined variable(s) (outside the condition variable itself) which I don't have. So all the mutex locking/unlocking and resultant blocking of B, C, D is just wasted overhead and pointless latency. pthread_cond_wait(3) says When using condition variables there is always a Boolean predicate involving shared variables associated with each condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return. I have no Boolean predicate (which presumably comprises the user-defined variables outside the condition variable I mentioned above), and I don't want spurious wakeups, so a pthreads condition variable would appear to be the wrong thing to use. Is there something like an event flag similar to a condition variable without spurious wakeup problem and without the extra overhead of the mutex and Boolean predicate. Or am I expected to build my own event flag using the aforesaid boolean predicate just to avoid the spurious wakeup problem? [I'm guessing this is the case...] -- Grant Edwards grant.b.edwardsYow! I'm DESPONDENT ... I at hope there's something gmail.comDEEP-FRIED under this miniature DOMED STADIUM ... Hi Grant, The best explanation I have read is this chapter: http://pages.cs.wisc.edu/~remzi/OSTEP/threads-cv.pdf from the book: http://pages.cs.wisc.edu/~remzi/OSTEP/ I know its 17 pages, but it is worth it! -- Andrés Becerra Sandoval
Re: [gentoo-user] OT: pthreads condition variable/mutex question
2014-08-13 12:36 GMT-05:00 Andrés Becerra Sandoval andres.bece...@gmail.com: 2014-08-13 12:21 GMT-05:00 Grant Edwards grant.b.edwa...@gmail.com: This is not Gentoo specific, and while I'm doing my prototyping and development on a Gentoo system, the eventual target is not going to be running Gentoo -- so feel free to ignore this thread or throw things at me. I'm trying to figure out how to synchronize threads which may be in different processes. Basically, I want thread A to be able to wake up any number of other threads B, C, D, ... who are all blocking until A says go (and who may or may not be in other processes). Other (mostly embedded) OSes I've used had some sort of event flag API that did exactly what I'm looking for, but I can't seem to find such a thing in pthreads. A condition variable in shared memory is the closest thing I have found, and my test applications are working OK (so far). But, I'm unclear on the purpose of the mutex whose address you pass to pthread_cond_wait(). Is it to prevent race conditions when manipulating the condition variable's internal state? I don't see how that can be the case, since the signal/broadcast call would have to be aware of it and it isn't. The mutex appears to be there to serialize access to some user-defined variable(s) (outside the condition variable itself) which I don't have. So all the mutex locking/unlocking and resultant blocking of B, C, D is just wasted overhead and pointless latency. pthread_cond_wait(3) says When using condition variables there is always a Boolean predicate involving shared variables associated with each condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return. I have no Boolean predicate (which presumably comprises the user-defined variables outside the condition variable I mentioned above), and I don't want spurious wakeups, so a pthreads condition variable would appear to be the wrong thing to use. Is there something like an event flag similar to a condition variable without spurious wakeup problem and without the extra overhead of the mutex and Boolean predicate. Or am I expected to build my own event flag using the aforesaid boolean predicate just to avoid the spurious wakeup problem? [I'm guessing this is the case...] -- Grant Edwards grant.b.edwardsYow! I'm DESPONDENT ... I at hope there's something gmail.comDEEP-FRIED under this miniature DOMED STADIUM ... Hi Grant, The best explanation I have read is this chapter: http://pages.cs.wisc.edu/~remzi/OSTEP/threads-cv.pdf from the book: http://pages.cs.wisc.edu/~remzi/OSTEP/ I know its 17 pages, but it is worth it! -- Andrés Becerra Sandoval In short: Withouth the use of the lock, the condition variable and a shared variable in concert you can get in trouble! -- Andrés Becerra Sandoval
Re: [gentoo-user] OT: pthreads condition variable/mutex question
2014-08-13 12:21 GMT-05:00 Grant Edwards grant.b.edwa...@gmail.com: This is not Gentoo specific, and while I'm doing my prototyping and development on a Gentoo system, the eventual target is not going to be running Gentoo -- so feel free to ignore this thread or throw things at me. You're close enough ;) I'll try to answer to the best of my ability, which is admittedly not much. I'm trying to figure out how to synchronize threads which may be in different processes. Basically, I want thread A to be able to wake up any number of other threads B, C, D, ... who are all blocking until A says go (and who may or may not be in other processes). Without knowing what you're doing, this sounds like a bad idea; if you *need* to synchronize threads, why aren't they running in the same process? If it's going to be running on Linux, you can send signals through the kernel's signal API; specifically HUP, USR1, and USR2 might be of interest to you. A condition variable in shared memory is the closest thing I have found, and my test applications are working OK (so far). But, I'm unclear on the purpose of the mutex whose address you pass to pthread_cond_wait(). I'm too much of a rookie to know how to do this; how are you sharing memory between processes? The mutex appears to be there to serialize access to some user-defined variable(s) (outside the condition variable itself) which I don't have. So all the mutex locking/unlocking and resultant blocking of B, C, D is just wasted overhead and pointless latency. This is definitely not a task for mutexes, a boolean or signaling would work much better. I'm not sure what exactly you're trying to do, but I hope this helps. If you can be more specific about the relationships between processes, I might be able to help more. Alec
Re: [gentoo-user] OT: pthreads condition variable/mutex question
On 13/08/2014 19:21, Grant Edwards wrote: This is not Gentoo specific, and while I'm doing my prototyping and development on a Gentoo system, the eventual target is not going to be running Gentoo -- so feel free to ignore this thread or throw things at me. I'm trying to figure out how to synchronize threads which may be in different processes. Basically, I want thread A to be able to wake up any number of other threads B, C, D, ... who are all blocking until A says go (and who may or may not be in other processes). Sounds like you a one talker - many listeners model. Have you considered a really simple solution like dbus? Other (mostly embedded) OSes I've used had some sort of event flag API that did exactly what I'm looking for, but I can't seem to find such a thing in pthreads. A condition variable in shared memory is the closest thing I have found, and my test applications are working OK (so far). But, I'm unclear on the purpose of the mutex whose address you pass to pthread_cond_wait(). Is it to prevent race conditions when manipulating the condition variable's internal state? I don't see how that can be the case, since the signal/broadcast call would have to be aware of it and it isn't. The mutex appears to be there to serialize access to some user-defined variable(s) (outside the condition variable itself) which I don't have. So all the mutex locking/unlocking and resultant blocking of B, C, D is just wasted overhead and pointless latency. pthread_cond_wait(3) says When using condition variables there is always a Boolean predicate involving shared variables associated with each condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return. I have no Boolean predicate (which presumably comprises the user-defined variables outside the condition variable I mentioned above), and I don't want spurious wakeups, so a pthreads condition variable would appear to be the wrong thing to use. Is there something like an event flag similar to a condition variable without spurious wakeup problem and without the extra overhead of the mutex and Boolean predicate. Or am I expected to build my own event flag using the aforesaid boolean predicate just to avoid the spurious wakeup problem? [I'm guessing this is the case...] -- Alan McKinnon alan.mckin...@gmail.com
