Re: [boost] This deadlocks on Linux but not on Windows <----- why this is important

From: Schrader, Glenn (gschrad_at_[hidden])
Date: 2008-02-08 08:18:22

The boost::interprocess library has a semaphore that should work even though its probably overkill.

-ges

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Colin Caughie
> Sent: Friday, February 08, 2008 3:00 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] This deadlocks on Linux but not on Windows <----- why
> this is important
>
> Clark Sims <clark_sims_boost <at> yahoo.com> writes:
>
> >
> > I defined this class for managing a thread group, with different
> priorities
> for different threads
> > http://rafb.net/p/u0LDDP45.html       I wrote this test example:
> http://rafb.net/p/bAIhrh79.html    it
> > works perfectly in linux,  generating this output :
> > http://acumenconsultinginc.net/linux.results.txt   on windows,  it calls
> the
> appropriate locks, but
> > it does not stop when two locks, lock the same mutex:
> http://acumenconsultinginc.net/windows.results.txt.
> >
> > My class for managing threads, based upon priorities, won't work unless
> the
> previous small code fragment deadlocks.
>
> Those URLs don't work for me, but presumably what you want is something
> that
> blocks until something is queued to be run by one of the threads in the
> group.
> My suggestion would be to use semaphores rather than mutexes for this. You
> initialize the semaphore count to 0 so that the first time you wait for it
> you
> immediately block. When another thread signals the semaphore you wake up.
>
> You'll have to write your own cross-platform semaphore class though as
> Boost.Thread doesn't have one.
>
> Colin
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost