Re: [boost] no semaphores in boost::thread

[Beman Dawes]

At 09:22 AM 6/4/2003, Stefan Seefeld wrote:
>hi there,
>
>I'v been trying to find some info as to why semaphores
>are considered harmful by the boost::thread authors,
>without luck. Is there any concise text describing
>the problem ?
I've expanded the FAQ entry to read:

Why has class semaphore disappeared?

Semaphore was removed as too error prone. The same effect can be achieved 
with greater safety by the combination of a mutex and a condition variable. 
Dijkstra (the semaphore's inventor), Hoare, and Brinch Hansen all 
depreciated semaphores and advocated more structured alternatives. 
[Andrews-83] summarizes typical errors as "omitting a P or a V, or 
accidentally coding a P on one semaphore and a V on on another", forgetting 
to include all references to shared objects in critical sections, and 
confusion caused by using the same primitive for "both condition 
synchronization and mutual exclusion".

The [Andrews-83] reference is to Gregory R. Andrews, Fred B. Schneider, 
Concepts and Notations for Concurrent Programming, ACM Computing Surveys, 
Vol. 15, No. 1, March, 1983. 
http://www.acm.org/pubs/citations/journals/surveys/1983-15-1/p3-andrews/

>I'v been using semaphores for years and can't think of
>what should be wrong with it.
That's what most programmers said about goto when Dijkstra's "Go To 
Statement Considered Harmful" was published. If you go back and read his 
letter (http://www.acm.org/classics/oct95/), you could substitute 
"semaphore" for "go to statement" in the key sentence: "The go to statement 
as it stands is just too primitive; it is too much an invitation to make a 
mess of one's program."

Goto's work (or worked; how long since you've seen one in a program?) 
Semaphores work. But we are better off without both of them.

--Beman



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] no semaphores in boost::thread

[Stefan Seefeld]

Robin Hu wrote:

> Semaphore can always be stimulated by using mutex + cond_var. and
> the only place that semaphore is a must is in signle-handler, but
> this is not within the area of threading programming. ;-)
right, semaphores can be emulated by other primitives. But does
that mean they *have to* be implemented that way ? I thought the point
of not including semaphores in boost::threads was that they were
error-prone or 'broken' in some other way, so I wanted to understand
why.
Actually, I'v already seen threading libraries where the windows version
implemented condition variables in terms of mutexes and semaphores, not
the other way around...
Regards,
Stefan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] no semaphores in boost::thread

[Robin Hu]

> "Stefan" == Stefan Seefeld <[EMAIL PROTECTED]> writes:

Stefan> hi there,

Stefan> I'v been trying to find some info as to why semaphores are
Stefan> considered harmful by the boost::thread authors, without
Stefan> luck. Is there any concise text describing the problem ?

Stefan> I'v been using semaphores for years and can't think of what
Stefan> should be wrong with it.

Semaphore can always be stimulated by using mutex + cond_var. and
the only place that semaphore is a must is in signle-handler, but
this is not within the area of threading programming. ;-)

Stefan> Thanks, Stefan


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost