Re: Threads: rw_mutex design + sample implementation

From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-03-12 05:26:46

--- In boost_at_y..., Darryl Green <green_at_t...> wrote:
> You don't need a complete user-space scheduler implementation as 
such - it is possible to implement appropriate blocking/waiting 
mechanisms that rely on the "native" scheduler and its 
synchronisation primitives but do the necessary housekeeping. The 
issue of FIFO, LIFO etc ordering can be dealt with relatively simply 
and extending it to do priority inheritance shouldn't be hard either. 
The first only requires keeping information about those tasks that 
are waiting, the latter requires keeping information about the 
current holder of a mutex (like) object as well. Dynamic priorities 
make this approach impractical, so it is only really applicable 
to "real time" tasks - which seems a reasonable constraint to me.
> 
> > Maybe acquiring the exclusive lock could include additional 
> > (optional) parameters indicative of the required priority boost?  
It 
> > seems like for most practical uses of rw_mutex, you would want 
anyone 
> > holding the exclusive lock to get in & out as quickly as possible 
if 
> > contention is likely.
> It feels like there might be a nasty rip below those smooth waters -
 I think
> offering an interface like this is asking for trouble?

Priority inheritance does seem like a general added feauture for many 
of the locking primitives.  Since the actual priority API details for 
each platform wouldn't have to be exposed, and the user wouldn't have 
to worry about specific "Set thread T1 to Priority P3 before locking 
Mutex M3".  I think this sounds much better than what I was alluding 
to.

This would of course be applicable to any synchronization primitive 
in Boost.Threads....

Regards,
Dave