RE: [boost] Re: Threads: rw_mutex design + sample implementation

From: Darryl Green (green_at_[hidden])
Date: 2002-03-11 21:18:49

> -----Original Message-----
> From: dmoore99atwork [mailto:dmoore_at_[hidden]]
> Sent: Tuesday, 12 March 2002 1:15 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Threads: rw_mutex design + sample implementation
> 
> 
> On the subject of priority inversion:
> 
> 
> Now, I can see where OTHER high priority threads in the same process 
> who were -Not- contending for the lock could interfere with the low-
> priority thread's ability to get its work done and release the lock.  
> This could happen for ordinary locks/mutexes too, right?
> 
> However, short of a complete user-space scheduler implementation, I 
> don't see what can be done in this case, save for the higher priority 
> threads running a timed wait for the lock, then taking action in 
> boosting/lowering priorities as needed.
> 
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?

> 
> Of course, this type of solution would require help from 
> boost::thread on priority levels, etc. which will be a nasty cross-
> platform portability issue....
> 
I think it would be better to offer priority inheritance, along with such
things as fairness as an attribute of the synchronisation primitives used.
On some platforms, this would just map to appropriate native synchronisation
objects. On others it would require more elaborate schemes, parts of which
would most likely require platform specific code. I don't think platform
specific code is a problem if it is kept localised to the lower levels of
the/a library. There may be problems in offering all facilities on all
platforms, which may reduce the applicability of these facilities in writing
truly cross-platform code, but I think even things like priorities can be
treated generically enough to allow the bulk of the code to be portable.