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
> 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.
> "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
> guarantee a particular scheduling order nor a particular bound on
> other threads can lock the mutex before any specific thread gets
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
> above sense.
I could be wrong, but I don't *think* they specify this (at least to
the extent that I think you are).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk