This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
RE: Interrupted IO and AWT
- To: "'Tom Tromey'" <tromey at cygnus dot com>, Jeff Sturm <jsturm at sigma6 dot com>
- Subject: RE: Interrupted IO and AWT
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Tue, 21 Mar 2000 16:05:38 -0800
- Cc: Bryce McKinlay <bryce at albatross dot co dot nz>, java-discuss at sourceware dot cygnus dot com
It seems to me that a spin lock with exponential back-off (and sleeps for
longer wait times) doesn't behave that badly, even in this case. There'll
be some unneeded wakeups on the part of the waiting thread near the
beginning, and it may sleep for up to about twice as long as it should
(assuming the base of the exponential is 2). Clearly this is suboptimal in
this case. But are there cases in which it's a serious problem?
Hans
-----Original Message-----
From: Tom Tromey [mailto:tromey@cygnus.com]
Sent: Tuesday, March 21, 2000 1:30 PM
To: Jeff Sturm
Cc: Boehm, Hans; Tom Tromey; Bryce McKinlay;
java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT
>>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:
Jeff> Unfortunately Java supports just one synchronization primitive
Jeff> which must behave reasonably in all scenarios, even if (e.g.) a
Jeff> thread blocks on I/O.
One option would be to implement locks so that an attempt to acquire a
lock which is held by an I/O-blocked thread would cause a real block
instead of a spin. There are a lot of tradeoffs to make if we take
this route.
It does seem that we'll want some sort of configurable scheme.
Nothing we can come up with will be right in 100% of the
circumstances. For "big" implementations we should definitely
consider an adaptive approach. If I ever have time I'll dig up the
literature on this stuff. Meanwhile, anybody with the rare
combination of motivation and time is welcome to take a shot.
Tom