[gclist] Mars Rover info from comp.risks

[Hans Boehm]

On Jan 7,  7:48pm, Fabio Riccardi wrote:
> Subject: Re: [gclist] Mars Rover info from comp.risks
> Hans Boehm writes:
>  > On Jan 7,  5:12pm, Fabio Riccardi wrote:
>  > > Condition variables are ment to share resources, so...
>  > >
>  > Could one of you clarify what this means?  In non-realtime code, if I have
a
>  > pthreads-like thread interface, pthread_cond_wait has no way of telling
what
>  > thread it's waiting for.  Indeed, if it's waiting for an instance of some
>  > instance to become available, it's waiting for whichever thread first
releases
That should have been instance of some RESOURCE.  Sorry.
>  > such an instance.
>
> priority inheritance, like other scheduling problems, has to be dealt
> by the scheduler, definitively not something you want to do by hand.
>
> As far as standards are concerned, the fact that pthreads is a broken
> interface doesn't mean that the problem cannot be solved... you need a
> slightly richer threading and locking semantics.

It seems to me that this actually changes the programming model significantly.
Condition variable waits in pthreads (or Java or Modula 3 or Mesa) cannot
easily specify the thread they are waiting for.  In a lot of code that's not
known.

>
> About who's waiting for what: to a lock is normally associated a list
> of waiting tasks, so the scheduler can always go in there and check
> the different process descriptors. You can also record which process
> is currntly holding the lock.

And pthread lock implementations generally do all of these for locks.  But
condition variables can be used to wait for any thread that happens to make
a resource available, or generates an event, or ...  There is no known set
of threads that you're waiting for.
>
> Of course, all this is for some kind of real-time.
>
And I'm perfectly happy to conclude that that's a very different problem
that requires different techniques, interfaces, programming models etc.
The problem is that we seem to get stuck with interfaces that are somewhere
in the middle (e.g. strict priorities with no way to do priority inheritance
for condition variables) that I'm not sure are optimal for anything.



-- 
Hans-Juergen Boehm
boehm@mti.sgi.com