[boost] Re: Semaphores?

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-05-23 07:57:58

Dave Jones wrote:
> 
> Are there any plans to add semaphores to the boost threads library?  Or
> are they already there and I missed them?  

< Forward Inline >

-------- Original Message --------
Message-ID: <3CECD17B.B8AE3459_at_[hidden]>
Date: Thu, 23 May 2002 13:24:43 +0200
From: Alexander Terekhov <terekhov_at_[hidden]>
Reply-To: terekhov_at_[hidden]
Newsgroups: comp.os.ms-windows.programmer.win32,comp.programming.threads,microsoft.public.win32.programmer.kernel
Subject: Re: The implementation of condition variables in pthreads-win32
References: <40726f20.0203260300.529bf1f3_at_[hidden]> <3CDF67F7.2890424_at_[hidden]> <uFrvvgo#BHA.1916_at_tkmsftngp04> <3CDFE0B4.FD7FD1EF_at_[hidden]> <e9d19pq#BHA.2344_at_tkmsftngp02> <3CE0C501.BEA63E94_at_[hidden]> <eEk4KY3#BHA.2336_at_tkmsftngp05> <3CE18E0C.F9EE7261_at_[hidden]> <u15b7m$#BHA.2520_at_tkmsftngp05> <3CE26636.2069C71B_at_[hidden]> <ueMYocM$BHA.1980_at_tkmsftngp04> <3CE3A44F.1ECC7192_at_[hidden]> <eRV52fN$BHA.2552_at_tkmsftngp05> <3CE53FA0.7080202_at_[hidden]> <eaSF1Qd$BHA.2384_at_tkmsftngp02> <c29b5e33.0205171527.281e98bc_at_[hidden]> <u30rXT2$BHA.1208_at_tkmsftngp02> <3CEA23F2.4F85F4E6_at_[hidden]> <uVLkL$LACHA.1836_at_tkmsftngp05> <3CEA50F8.28BD70CD_at_[hidden]> <3CEABA5A.6060102_at_[hidden]> <3CEAD4C0.184B33E5_at_[hidden]> <3CEBBAB2.9070703_at_[hidden]>

Daniel Miller wrote:
[...]
>    This isn't about one-upmanship competition between semaphores &
> condition-variables.  This isn't about a fight-to-the-death between semaphores &
> condition-variables (because I am not in favor of the death of either one).
> This is about teaching tolerance of both.

First off, this is about UNDERSTANDING *pros and cons* 
w.r.t. different SYNCHRONIZATION CONCEPTS/TOOLS (modern
POSIX mutexes & condvars on one side and archaic POSIX 
semas on another side... MS-win32-silliness/brain-damaged-
stuff aside) AND IN THE CONTEXT OF *THREADS* >>"medium to 
fine-grained structuring mechanism for parallelism in an 
application"<< (*NOT* SIGNALS, IPC, or whatever things 
"like that").

>    If in a completely different context I were to argue against racism inflicted
> against human race x for example, I would not attempt to show the superiority of
> x to another race y (neither macroscopically for all desirable metrics nor
> microscopically for any single one desirable metric), nor would I need to do so,
> nor should anyone compel me to do so.  But, I would try to undermine any claims
> that y is vastly superior to x in every desirable metric---a symptom of the
> racism against x---by attempting to teach tolerance of x as an equal peer of y
> where each has its strengths & weaknesses.  But also, I would try to undermine
> any claims that x should be thoroughly exterminated---a symptom of the racism
> against x.  I would argue that races x and y both should be allowed to co-exist
> in a live-&-let-live philosophy.  Let them go forth, live long, and prosper.

Hehe. ;-) Is this an attempt to trigger Godwin's Law? ;-) ;-)

>    Again Alexander, I am very curious about your viewpoints regarding the
> inclusion of support for POSIX's semaphores in a hypothetical POSIX.C++ since
> you advocate a more limited concept which you refer to as pthreads++ which
> presumably omits semaphores.  

Yep (hypothetical pthreads++ SHOULD DEFINITELY 
OMIT SEMAPHORES, I believe strongly).

> Could you tolerate some future POSIX.C++ binding
> for POSIX.1 which includes semaphores (since POSIX.C++ would be a strict
> superset [including among other things: semaphores] of your pthreads++ vision)?

Yup (see below).

>   Or would the mere presence of semaphores in that hypothetical POSIX.C++ lead
> to your opposition to that POSIX.C++ including semaphores?  

Nope (and relevance/importance of my "humble
opposition/tolerance" aside; I don't really think 
that anyone cares much in regards to my "opposition" 
and/or "tolerance" whether it's humble or not ;-)).

Hypothetical POSIX.1++ (POSIX.C++) would have to provide 
semas to perform signaling from async.signal handlers
and for IPC (in both cases there could/should be {almost}
NO thread-shared memory involved, which, otherwise, could 
and SHOULD be used *for mutexes and condvars to build
whatever sync.protocols "over" thread-shared data*). 
That's it. Since neither signals nor IPC should (IMNSHO) 
be a part of "limited concept which I refer to as 
pthreads++", they aren't really welcomed/needed 
there (in pthreads++, I mean).

regards,
alexander.