At Thursday 2004-02-19 00:08, you wrote:
Craig Rodrigues wrote:
Look the the phrase "Much experience with semaphores shows" and futher paragraphs. In essense, it's says that semaphores are for signal handlers and for inter-process synchronization and discourages their use anywhere else.
That's an interesting link, thanks! I don't interpret the text in the same way that you do, but maybe I am not understanding something properly.
Maybe I don't, either. The standard cannot make definitive statements that "semaphore is bad". Folks on comp.programming.threads newsgroup seem to make such statements in more clear language ;-)
Further down from "Much experience with semaphores shows", there is this text:
"Counting semaphores are well matched to dealing with producer/consumer problems, including those that might exist between threads of different processes, or between a signal handler and a thread. In the former case, there may be little or no memory shared by the processes; in the latter case, one is not communicating between co-equal threads, but between a thread and an interrupt-like entity. It is for these reasons that IEEE Std 1003.1-2001 allows semaphores to be used by threads."
Doesn't it say that semaphores are retained for inter-process communication and for signal handlers?
This is the use-case that I am interested in.
Which one? Signal handler or inter-process communication?
does it really matter? semaphores are useful (and can be misused, like a lot of other things in life). Why the resistance to putting them in?
- Volodya
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"