Re: Patch [ecj]: Central Parking

[Andrew Haley <aph at redhat dot com>]

Mohan Embar writes:

 > > > This does away with _Jv_ThreadPark and _Jv_ThreadUnpark and keeps
 > > > park() and unpark() in natUnsafe.cc, thereby allowing a shared
 > > > implementation using the cross-platform synchronization functions
 > > > and objects in posix-threads.h and win32-threads.h.  Since the
 > > > park() implementation uses _Jv_CondNotify, we also get thread
 > > > interrupt support for free and can do away with the
 > > > _Jv_ThreadUnpark call in Thread.interrupt().
 > >
 > >Surely it's possible to avoid this: the POSIX version doesn't need to
 > >call _Jv_CondWait and _Jv_CondNotify, and I don't see why the Win
 > >version should either.  But I guess I don't really mind what the Win
 > >version does, as long as it passes the tests.
 > 
 > My first inclination was to avoid going down this route too, but:
 > 
 > - Doesn't using _Jv_CondWait make for nicer, cleaner code, both for
 >   the POSIX version and in terms of reuse?

I don't see how it's cleaner.  _Jv_CondWait() is rather
over-engineered: it has a ton of side-effects beyond simply calling
pthread_cond_wait().

It would be very nice if we had a simple portable wrapper around
pthread_cond_wait().

It's important to realize what park() is for.  It's a
super-lightweight primitive intended to be the simplest base for more
complex operations.  Defining park() in terms of more complex
"primitives" somewhat defeats the object.  Just look at how much
simpler _Jv_ThreadPark is than _Jv_CondWait, for example.

 > - I'm not seeing that we need to be overly concerned about
 >   speed here, since all we're doing is making our bed so
 >   we can take a nap.
 > - Isn't it nice to cerntralize interrupt handling in one spot? I thought
 >   it was cool that I was able to eliminate the call to unpark() in
 >   Thread.interrupt() and simply augment the comment at the end of
 >   the call to _Jv_CondWait in park() that this could also occur
 >   for an interrupt in addition to a timeout.
 > 
 > So my feeling was that these benefits outweighed whatever added overhead
 > _Jv_CondWait entailed, even for the POSIX version.
 > 
 > >I used the TCK at
 > >http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/.
 > 
 > If I can get this to pass these tests for the Linux native build, would
 > you be open to proceeding down this route or not?

I guess I would acquiesce, but I don't think it's the right road to go
down.  I don't know how the interaction with thread->state would work
out.

Andrew.