Boost logo

Boost :

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?
> > seems like for most practical uses of rw_mutex, you would want
> > holding the exclusive lock to get in & out as quickly as possible
> > 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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at