Re: Weak semaphores in Boost threads library

From: williamkempf_at_[hidden]
Date: 2001-10-17 13:41:27

--- In boost_at_y..., "Kevin S. Van Horn" <kevin.vanhorn_at_n...> wrote:
> On Wed, 17 Oct 2001 williamkempf_at_h... wrote:
> 
> > --- In boost_at_y..., kevin_vanhorn_at_n... wrote:
> > > > I just noticed, to my dismay, that the thread library only
> > > > implements weak semaphores.
> >
> > Not precisely true.  The Win32 implementation isn't a "weak"
> > implementation.  The POSIX one may well be, however.  I'll
> > investigate.
> 
> Regardless of how it is resolved, I think the documentation needs to
> discuss the issue of weak vs. strong vs. fair semaphores, and make 
it clear
> which you are getting.

I'll look into this when I can as well, though some of this is going 
to have to be unspecified (read below).

> The issue of fair vs. unfair also shows up in discussing mutexes.  
The default
> "Unspecified" policy guarantees too little; the 
(unimplemented) "FIFO" policy
> guarantees too much.  It would be useful to define and implement a 
mutex with a
> "Fair" scheduling policy, which guarantees lack of starvation but 
does not
> guarantee a particular scheduling order nor a particular bound on 
how many
> other threads can lock the mutex before any specific thread gets 
its turn.

I'd hope that if Boost.Threads is accepted into the standard that 
they specify this sort of thing.  However, for Boost.Threads today 
it's not really possible (at least not feasable) to specify this.  We 
rely too heavily on the underlying threading libraries and enforcing 
any policies here will thus be problematic.
 
> I'm not sure whether or not POSIX mutexes are guaranteed to be fair 
in the
> above sense.

I could be wrong, but I don't *think* they specify this (at least to 
the extent that I think you are).

Bill Kempf