Patch [ecj]: Central Parking
Mohan Embar
gnustuff@thisiscool.com
Wed Dec 6 12:48:00 GMT 2006
Hi Andrew,
> > 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'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?
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/
More information about the Java-patches
mailing list