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
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,
"Victor A. Wagner, Jr." <vawjr@rudbek.com> wrote in message news:6.0.3.0.2.20040219140935.0448ef10@mail.rudbek.com... producer/consumer like a
lot of other things in life). Why the resistance to putting them in?
For my part, I don't really have a strong opinion one way or the other yet, but even if I decided I strongly supported adding semaphores to Boost.Thread, I wouldn't have time to do anything about it for quite a while. Are you (or is anyone else) willing to submit a design that minimizes the possibilities of misuse, since that appears to be the main concern? And, if Boosters like the design, are you (or is anyone else) willing to implement it on the same platforms supported by the current Boost.Thread? And write documentation that clearly states the intended use cases and drawbacks of semaphores? And write unit tests, examples, etc.? Perhaps one way to limit the possibilities for misuse would be to create a class or classes that, instead of directly exposing semaphore functionality, somehow supports the main use cases for semaphores? I don't really have a clear idea what this would mean--I'm just thinking out loud. Any ideas? Mike
- 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"