JDK-8146527: Absolute Scheduling / Request for Comments

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Request for Comments

Markus KARG
The Windows OS _does_ provide different types of clocks.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of David Holmes
Sent: Sonntag, 10. Januar 2016 23:43
To: [hidden email]
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling / Request for Comments

I think Alex hits the nail on the head here. For these API's to work "correctly" in these difference contexts we have to make "time" an explicit part of the API and in particular we do need a notion of different Clocks that represent different kinds of "time". The Real-time Specification for Java did try to go down this path but ran into serious practical limitations - if the operating system doesn't support different kinds of clocks and the API's they expose don't allow control of the clocks involved, then implementing such abstractions in an efficient and practical way is exceedingly difficult, to say the least.

David
-------

> -----Original Message-----
> From: [hidden email] [mailto:concurrency-
> [hidden email]] On Behalf Of Alex Otenko
> Sent: Sunday, January 10, 2016 12:04 PM
> To: Nathan & Ila Reynolds <[hidden email]>
> Cc: [hidden email]
> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
>
> I would expect these to be case-specific.
>
> The flow of time is different in different frames of reference. Mailer wants it
> to be tied to the frame of reference coinciding with mail server (which is in
> the same frame as Greenwich), Sudoku game wants it tied to the frame of
> reference coinciding with Sudoku process space - it doesn�t want to count
> time towards the score whilst the game is not in the foreground.
>
> It would be nice to have a replaceable clock, or the source of time for
> individual condvars.
>
> Alex
>
> > On 9 Jan 2016, at 17:18, Nathan & Ila Reynolds <[hidden email]>
> wrote:
> >
> > Also, Windows fires an event to all applications when the system resumes
> after hibernation.  You could use that event instead of polling.
> >
> > ScheduledExecutorService provides schedule(), scheduleAtFixedRate() and
> scheduleWithFixedDelay().  I expect schedule() to run the command at or
> very soon after the delay or as soon as the machine resumes if the delay has
> elapsed.  I expect scheduleAtFixedRate() to run the command N times
> rapidly if hibernation lasted N periods.  I expect scheduleWithFixedDelay() to
> run the command one time at or very soon after the delay or as soon as the
> machine resumes.  In this regard, the programmer has control whether they
> need N times or 1 time after hibernation.  I only use scheduleAtFixedRate() if
> I have something staying in sync with the passage of time.  I use
> scheduleWithFixedDelay() in all other cases because if the command takes a
> long time, I don't need it to run right away.
> >
> >
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ScheduledE
> xecutorService.html
> >
> > -Nathan
> >
> > -----Original Message-----
> > From: [hidden email] [mailto:concurrency-
> [hidden email]] On Behalf Of Markus KARG
> > Sent: Saturday, January 09, 2016 6:58 AM
> > To: 'Carsten Schipke' <[hidden email]>
> > Cc: [hidden email]
> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
> >
> > Carsten,
> >
> > the Windows API provides several different methods for timing. Some of
> them are definitively able to fire at a particular point in time, independent of
> any hibernation.
> >
> > In case a different OS won't have such a factility, there is a simple fallback:
> Triggering events more often, checking the actual time (in pure Java), so we
> find out whether to wait further, or whether the event is to be fired. This,
> BTW, is the workaround applied by pure Java solutions currently, hence what
> I'd like to get rid off by this feature request. :-)
> >
> > -Markus
> >
> >
> > -----Original Message-----
> > From: Carsten Schipke [mailto:[hidden email]]
> > Sent: Samstag, 9. Januar 2016 14:09
> > To: Markus KARG
> > Cc: [hidden email]
> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
> >
> > sure, as I mentioned, I have never really had that requirement, it just
> sounded to me like many programmers could have many slightly different
> requirements on such an API. I also don�t know what the Windows API
> offers in those regards / how its solved there, but if there is such a widely
> accepted solution, then it surely would make sense as you say.
> >
> >
> >> On Jan 9, 2016, at 21:04, Markus KARG <[hidden email]>
> wrote:
> >>
> >> I think it should be up to the programmer (e. g. by passing a flag or using
> different methods) whether he wants 10 events after missing those while
> hibernation, or whether he wants the events to be collapsed into one single
> event alternatively. BTW, I never said that the API must support an absolute
> variant of repeated event schedulung. You could also simply provide an
> absolute variant of the "fire ONCE" method, and the mail application has to
> reschedule inside of the event handler.
> >>
> >> Hooks are out of scope for my proposal, as they solve a different problem
> and are working on a deeper level (the scheduler API could certainly make
> use of such hooks). In case the Windows API for example would be able to
> solve the problem for us (it is, BTW), why shouldn't we provide a Java API
> wrapping that (without running into any rattail, as we simply offload)?
> >>
> >> -Markus
> >>
> >> -----Original Message-----
> >> From: Carsten Schipke [mailto:[hidden email]]
> >> Sent: Samstag, 9. Januar 2016 11:02
> >> To: Markus KARG
> >> Cc: [hidden email]
> >> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
> >>
> >> �...or it will fire instantly after the end of hibernation �� considering your
> example of hourly/periodically checking mails, that would mean that the
> program checks your mailbox 10 times at once after 10h hibernation.
> >> So the API would also need to know whether unfired events should
> queue up over time. Sounds like a rattail pulling endlessly use cases &
> requirements behind it.
> >>
> >> I for one never thought about using the JVM to schedule things that live
> through hibernation or similar (not knowing the original intention of the API).
> But I have also never built daemon-like desktop/client applications/services.
> >>
> >> I guess in case of JVM, one could argue that specifications only apply at
> runtime, and hibernation is interrupting that. Maybe it would be better to
> provide hooks e.g. in the Runtime class to allow callbacks on pre-/post-
> hibernation, standby, signals etc. Then one could de/attach events
> accordingly.
> >>
> >>
> >>> On Jan 9, 2016, at 17:28, Markus KARG <[hidden email]>
> wrote:
> >>>
> >>> The following requests comments on a Feature Proposal for Absolute
> Scheduling.
> >>>
> >>> OpenJDK ticket JDK-8146527
> (https://bugs.openjdk.java.net/browse/JDK-8146527) describes the
> following case:
> >>>
> >>> * ScheduledExecutorService.schedule() is invoked to schedule firing of
> an event "in one minute".
> >>> * The laptop lid gets closed instantly after that, so hibernation will occur,
> hence the JVM will suspend.
> >>> * After thirty seconds of hibernation, the laptop lid gets openen, so
> hibernation will cancel and the JVM resumes.
> >>> * Despite the expected result (one minute after start of program the
> event does occur), the event actually is delayed by the length of the
> hibernation phase, and happens 90 seconds after the program was started.
> In the expectation of the end user, the event fired 30 seconds "too late"!
> >>>
> >>> This is annoying to users and rather unexpected and astonishing for
> programmers literally following the words of the JavaDocs. Clearly the
> provided deadline is a relative value in the physical sense ("one minute from
> now, independent of what 'now' is currently like"), but certainly what the
> user actually expects it to work like is an absolute value in the physical sense
> ("one minute from now, where 'now' is the current point on the time axis of
> the Universe, hence unaffected by hibernation). Whether or not the laptop
> was closed temporarily in the meantime plays no role to the expectation of
> neither the end user nor the application provider.
> >>>
> >>> Unfortunately there is no other API that allows the application vendor to
> define that the deadline it meant to be unaffected of hibernation. Clearly
> this is a drawback to the Java platform, as many applications need such a
> behaviour (like "check my mails once per hour" - if you open your laptop lid
> ONLY for a few minutes to see whether meanwhile new emails arrived or not
> [like, BTW, some laptops are able to perform these days, even with the lid
> closed, thanks to a BIOS timer] you won't receive any new emails ever as
> "JVM" time progresses only be few minutes per day then).
> >>>
> >>> A solution could be the addition of a special variant of
> ScheduledExecutorService.schedule(absoluteInstant) which is unaffected of
> any hibernation, and will fire either exactly at the absoluteInstant (in case the
> laptop is not hibernating _currently_), or it will fire instantly after the end of
> hibernation, in case the laptop was hibernating at absoluteInstant.
> >>>
> >>> There are two possible ways to reach this: Either there is an OS-specific
> API that alrady provides exactly that behaviour, or the JVM needs to be
> informed every 'x' fractions of "discontinuous jvm time" to find out how
> much "continuous real world time" has advanced and whether a scheduled
> event was missed meanwhile (which is the workaround such applications
> have to perform on their own currently to workaround the problem). The
> first is problematic due to changes in the implementations of the APIs (e. g.
> Windows changed some APIs from "continuous time" to using
> "discontinuous time"), the second is complex in finding the optimal value of
> 'x' (too low means high power consumption, too high means firing too late
> after the deadline).
> >>>
> >>> Side note: To be unambiguous, the new deadline should possibly be
> typed as java.time.Instant, as that could never be misunderstood as
> "discontinous jvm time" inherently.
> >>>
> >>> What is your opinion on that?
> >>>
> >>> -Markus
> >>> _______________________________________________
> >>> Concurrency-interest mailing list
> >>> [hidden email]
> >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Request for Comments

Andrew Haley
In reply to this post by Markus KARG
On 01/11/2016 04:37 PM, Markus KARG wrote:
> It depends on the use case, so the application programmer should decide
> whether he wants coalesced events, an event storm, or the current behaviour
> (delayed).

But the application programmer may not even know that their
application is being used in such an environment.  It's a deployment
issue.

Andrew.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Request for Comments

Markus KARG
The application programmer knows very well whether he wants to have absolute
time (non-affected of hibernation), or whether he don't cares if time is
delayed (affected of hibernation). Whether or not hibernation actually
occurs is of no interest when using the "right" API then. The deployer on
the other hand know whether hibernation will occur, but cannot know whether
delayed time will harm the use case of the application. So *only* the
application programmer can decide safely for the correct API.

-----Original Message-----
From: Andrew Haley [mailto:[hidden email]]
Sent: Montag, 11. Januar 2016 17:46
To: Markus KARG; [hidden email]
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
Request for Comments

On 01/11/2016 04:37 PM, Markus KARG wrote:
> It depends on the use case, so the application programmer should decide
> whether he wants coalesced events, an event storm, or the current
behaviour
> (delayed).

But the application programmer may not even know that their
application is being used in such an environment.  It's a deployment
issue.

Andrew.


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Request for Comments

David Holmes-6
In reply to this post by Markus KARG
Markus KARG writes:
>
> The Windows OS _does_ provide different types of clocks.

Not to the extent described by Alex ie relative clocks that track across suspension, relative clocks that don't. There is only a single relative time clock and a single absolute time clock - and the Windows synchronization API's don't let you specify which clock you want to use for timeouts - they are simply relative with whatever suspension semantics windows has chosen.

David
-------
 

> -----Original Message-----
> From: [hidden email] [mailto:concurrency-
> [hidden email]] On Behalf Of David Holmes
> Sent: Sonntag, 10. Januar 2016 23:43
> To: [hidden email]
> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> Request for Comments
>
> I think Alex hits the nail on the head here. For these API's to work "correctly"
> in these difference contexts we have to make "time" an explicit part of the
> API and in particular we do need a notion of different Clocks that represent
> different kinds of "time". The Real-time Specification for Java did try to go
> down this path but ran into serious practical limitations - if the operating
> system doesn't support different kinds of clocks and the API's they expose
> don't allow control of the clocks involved, then implementing such
> abstractions in an efficient and practical way is exceedingly difficult, to say
> the least.
>
> David
> -------
>
> > -----Original Message-----
> > From: [hidden email] [mailto:concurrency-
> > [hidden email]] On Behalf Of Alex Otenko
> > Sent: Sunday, January 10, 2016 12:04 PM
> > To: Nathan & Ila Reynolds <[hidden email]>
> > Cc: [hidden email]
> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> > Request for Comments
> >
> > I would expect these to be case-specific.
> >
> > The flow of time is different in different frames of reference. Mailer wants
> it
> > to be tied to the frame of reference coinciding with mail server (which is in
> > the same frame as Greenwich), Sudoku game wants it tied to the frame of
> > reference coinciding with Sudoku process space - it doesn?t want to count
> > time towards the score whilst the game is not in the foreground.
> >
> > It would be nice to have a replaceable clock, or the source of time for
> > individual condvars.
> >
> > Alex
> >
> > > On 9 Jan 2016, at 17:18, Nathan & Ila Reynolds <[hidden email]>
> > wrote:
> > >
> > > Also, Windows fires an event to all applications when the system
> resumes
> > after hibernation.  You could use that event instead of polling.
> > >
> > > ScheduledExecutorService provides schedule(), scheduleAtFixedRate()
> and
> > scheduleWithFixedDelay().  I expect schedule() to run the command at or
> > very soon after the delay or as soon as the machine resumes if the delay
> has
> > elapsed.  I expect scheduleAtFixedRate() to run the command N times
> > rapidly if hibernation lasted N periods.  I expect scheduleWithFixedDelay()
> to
> > run the command one time at or very soon after the delay or as soon as the
> > machine resumes.  In this regard, the programmer has control whether
> they
> > need N times or 1 time after hibernation.  I only use scheduleAtFixedRate()
> if
> > I have something staying in sync with the passage of time.  I use
> > scheduleWithFixedDelay() in all other cases because if the command takes
> a
> > long time, I don't need it to run right away.
> > >
> > >
> >
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ScheduledE
> > xecutorService.html
> > >
> > > -Nathan
> > >
> > > -----Original Message-----
> > > From: [hidden email]
> [mailto:concurrency-
> > [hidden email]] On Behalf Of Markus KARG
> > > Sent: Saturday, January 09, 2016 6:58 AM
> > > To: 'Carsten Schipke' <[hidden email]>
> > > Cc: [hidden email]
> > > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> > Request for Comments
> > >
> > > Carsten,
> > >
> > > the Windows API provides several different methods for timing. Some of
> > them are definitively able to fire at a particular point in time, independent
> of
> > any hibernation.
> > >
> > > In case a different OS won't have such a factility, there is a simple fallback:
> > Triggering events more often, checking the actual time (in pure Java), so
> we
> > find out whether to wait further, or whether the event is to be fired. This,
> > BTW, is the workaround applied by pure Java solutions currently, hence
> what
> > I'd like to get rid off by this feature request. :-)
> > >
> > > -Markus
> > >
> > >
> > > -----Original Message-----
> > > From: Carsten Schipke [mailto:[hidden email]]
> > > Sent: Samstag, 9. Januar 2016 14:09
> > > To: Markus KARG
> > > Cc: [hidden email]
> > > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> > Request for Comments
> > >
> > > sure, as I mentioned, I have never really had that requirement, it just
> > sounded to me like many programmers could have many slightly different
> > requirements on such an API. I also don?t know what the Windows API
> > offers in those regards / how its solved there, but if there is such a widely
> > accepted solution, then it surely would make sense as you say.
> > >
> > >
> > >> On Jan 9, 2016, at 21:04, Markus KARG <[hidden email]>
> > wrote:
> > >>
> > >> I think it should be up to the programmer (e. g. by passing a flag or using
> > different methods) whether he wants 10 events after missing those while
> > hibernation, or whether he wants the events to be collapsed into one
> single
> > event alternatively. BTW, I never said that the API must support an
> absolute
> > variant of repeated event schedulung. You could also simply provide an
> > absolute variant of the "fire ONCE" method, and the mail application has to
> > reschedule inside of the event handler.
> > >>
> > >> Hooks are out of scope for my proposal, as they solve a different
> problem
> > and are working on a deeper level (the scheduler API could certainly make
> > use of such hooks). In case the Windows API for example would be able to
> > solve the problem for us (it is, BTW), why shouldn't we provide a Java API
> > wrapping that (without running into any rattail, as we simply offload)?
> > >>
> > >> -Markus
> > >>
> > >> -----Original Message-----
> > >> From: Carsten Schipke [mailto:[hidden email]]
> > >> Sent: Samstag, 9. Januar 2016 11:02
> > >> To: Markus KARG
> > >> Cc: [hidden email]
> > >> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
> > Request for Comments
> > >>
> > >> ?...or it will fire instantly after the end of hibernation ?? considering your
> > example of hourly/periodically checking mails, that would mean that the
> > program checks your mailbox 10 times at once after 10h hibernation.
> > >> So the API would also need to know whether unfired events should
> > queue up over time. Sounds like a rattail pulling endlessly use cases &
> > requirements behind it.
> > >>
> > >> I for one never thought about using the JVM to schedule things that live
> > through hibernation or similar (not knowing the original intention of the
> API).
> > But I have also never built daemon-like desktop/client
> applications/services.
> > >>
> > >> I guess in case of JVM, one could argue that specifications only apply at
> > runtime, and hibernation is interrupting that. Maybe it would be better to
> > provide hooks e.g. in the Runtime class to allow callbacks on pre-/post-
> > hibernation, standby, signals etc. Then one could de/attach events
> > accordingly.
> > >>
> > >>
> > >>> On Jan 9, 2016, at 17:28, Markus KARG <[hidden email]>
> > wrote:
> > >>>
> > >>> The following requests comments on a Feature Proposal for Absolute
> > Scheduling.
> > >>>
> > >>> OpenJDK ticket JDK-8146527
> > (https://bugs.openjdk.java.net/browse/JDK-8146527) describes the
> > following case:
> > >>>
> > >>> * ScheduledExecutorService.schedule() is invoked to schedule firing of
> > an event "in one minute".
> > >>> * The laptop lid gets closed instantly after that, so hibernation will
> occur,
> > hence the JVM will suspend.
> > >>> * After thirty seconds of hibernation, the laptop lid gets openen, so
> > hibernation will cancel and the JVM resumes.
> > >>> * Despite the expected result (one minute after start of program the
> > event does occur), the event actually is delayed by the length of the
> > hibernation phase, and happens 90 seconds after the program was started.
> > In the expectation of the end user, the event fired 30 seconds "too late"!
> > >>>
> > >>> This is annoying to users and rather unexpected and astonishing for
> > programmers literally following the words of the JavaDocs. Clearly the
> > provided deadline is a relative value in the physical sense ("one minute
> from
> > now, independent of what 'now' is currently like"), but certainly what the
> > user actually expects it to work like is an absolute value in the physical
> sense
> > ("one minute from now, where 'now' is the current point on the time axis
> of
> > the Universe, hence unaffected by hibernation). Whether or not the
> laptop
> > was closed temporarily in the meantime plays no role to the expectation of
> > neither the end user nor the application provider.
> > >>>
> > >>> Unfortunately there is no other API that allows the application vendor
> to
> > define that the deadline it meant to be unaffected of hibernation. Clearly
> > this is a drawback to the Java platform, as many applications need such a
> > behaviour (like "check my mails once per hour" - if you open your laptop lid
> > ONLY for a few minutes to see whether meanwhile new emails arrived or
> not
> > [like, BTW, some laptops are able to perform these days, even with the lid
> > closed, thanks to a BIOS timer] you won't receive any new emails ever as
> > "JVM" time progresses only be few minutes per day then).
> > >>>
> > >>> A solution could be the addition of a special variant of
> > ScheduledExecutorService.schedule(absoluteInstant) which is unaffected
> of
> > any hibernation, and will fire either exactly at the absoluteInstant (in case
> the
> > laptop is not hibernating _currently_), or it will fire instantly after the end
> of
> > hibernation, in case the laptop was hibernating at absoluteInstant.
> > >>>
> > >>> There are two possible ways to reach this: Either there is an OS-specific
> > API that alrady provides exactly that behaviour, or the JVM needs to be
> > informed every 'x' fractions of "discontinuous jvm time" to find out how
> > much "continuous real world time" has advanced and whether a scheduled
> > event was missed meanwhile (which is the workaround such applications
> > have to perform on their own currently to workaround the problem). The
> > first is problematic due to changes in the implementations of the APIs (e. g.
> > Windows changed some APIs from "continuous time" to using
> > "discontinuous time"), the second is complex in finding the optimal value of
> > 'x' (too low means high power consumption, too high means firing too late
> > after the deadline).
> > >>>
> > >>> Side note: To be unambiguous, the new deadline should possibly be
> > typed as java.time.Instant, as that could never be misunderstood as
> > "discontinous jvm time" inherently.
> > >>>
> > >>> What is your opinion on that?
> > >>>
> > >>> -Markus
> > >>> _______________________________________________
> > >>> Concurrency-interest mailing list
> > >>> [hidden email]
> > >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >>
> > >>
> > >
> > >
> > >
> > > _______________________________________________
> > > Concurrency-interest mailing list
> > > [hidden email]
> > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > >
> > >
> > > _______________________________________________
> > > Concurrency-interest mailing list
> > > [hidden email]
> > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Request for Comments

Doug Lea
In reply to this post by Markus KARG
On 01/09/2016 04:28 AM, Markus KARG wrote:
> The following requests comments on a Feature Proposal for Absolute Scheduling.
>
> OpenJDK ticket JDK-8146527 (https://bugs.openjdk.java.net/browse/JDK-8146527)
> describes the following case:

Everyone wants time-related functions to do The Right Thing,
for evolving notions of The Right Thing.

The Right Thing should also be compatible with how Android
deals with deep-sleep etc. See
http://developer.android.com/reference/android/os/SystemClock.html

The main obstacle is finding people to invest substantial time
to work on the intricate and messy JVM support. If anyone is looking
for a challenging OpenJDK problem to work on long-term, this might
be a good choice.

-Doug

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Request for Comments

Markus KARG
Does that mean that the decision, how the future API shall look like IN THE
FUTURE is dependent of whether we can find a volunterr NOW?
-Markus

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Doug Lea
Sent: Dienstag, 12. Januar 2016 13:11
To: [hidden email]
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /
Request for Comments

On 01/09/2016 04:28 AM, Markus KARG wrote:
> The following requests comments on a Feature Proposal for Absolute
Scheduling.
>
> OpenJDK ticket JDK-8146527
> (https://bugs.openjdk.java.net/browse/JDK-8146527)
> describes the following case:

Everyone wants time-related functions to do The Right Thing, for evolving
notions of The Right Thing.

The Right Thing should also be compatible with how Android deals with
deep-sleep etc. See
http://developer.android.com/reference/android/os/SystemClock.html

The main obstacle is finding people to invest substantial time to work on
the intricate and messy JVM support. If anyone is looking for a challenging
OpenJDK problem to work on long-term, this might be a good choice.

-Doug

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Request for Comments

Martin Buchholz-3
In reply to this post by Doug Lea
On Tue, Jan 12, 2016 at 4:10 AM, Doug Lea <[hidden email]> wrote:

> The Right Thing should also be compatible with how Android
> deals with deep-sleep etc. See
> http://developer.android.com/reference/android/os/SystemClock.html

TIL about CLOCK_BOOTTIME
http://stackoverflow.com/questions/6360210/androidlinux-uptime-using-clock-monotonic/6360726#6360726
So this is much messier and harder to fix - it's not just a windows bug!
Windows and Linux actually agree!  Both stop the clock while the
system is suspended.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Requestfor Comments

Timo Kinnunen
In reply to this post by David Holmes-6

Hi,

 

I find this hard to believe. According to MSDN, these functions are available:

 

 

Includes sleeping time

Adjusted to external time reference

Highest resolution

QueryPerformanceCounter, QueryUnbiasedInterruptTimePrecise

No

No

Yes

GetSystemTimePreciseAsFileTime

Yes

Yes

Yes

QueryInterruptTimePrecise

Yes

No

Yes

GetSystemTimeAsFileTime

Yes

Yes

No

GetTickCount64, QueryInterruptTime

Yes

No

No

QueryUnbiasedInterruptTime

No

No

No

 

Since synchronizing time to an external UTC time source implies tracking time that elapses during system sleep, that table covers all possible combinations.

 

Let it not be said that Windows doesn’t have enough clocks 😊

 






--
Have a nice day,
Timo

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Monday, January 11, 2016 22:16
To: [hidden email]
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling / Requestfor Comments

 

Markus KARG writes:

>

> The Windows OS _does_ provide different types of clocks.

 

Not to the extent described by Alex ie relative clocks that track across suspension, relative clocks that don't. There is only a single relative time clock and a single absolute time clock - and the Windows synchronization API's don't let you specify which clock you want to use for timeouts - they are simply relative with whatever suspension semantics windows has chosen.

 

David

-------

> -----Original Message-----

> From: [hidden email] [mailto:concurrency-

> [hidden email]] On Behalf Of David Holmes

> Sent: Sonntag, 10. Januar 2016 23:43

> To: [hidden email]

> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /

> Request for Comments

>

> I think Alex hits the nail on the head here. For these API's to work "correctly"

> in these difference contexts we have to make "time" an explicit part of the

> API and in particular we do need a notion of different Clocks that represent

> different kinds of "time". The Real-time Specification for Java did try to go

> down this path but ran into serious practical limitations - if the operating

> system doesn't support different kinds of clocks and the API's they expose

> don't allow control of the clocks involved, then implementing such

> abstractions in an efficient and practical way is exceedingly difficult, to say

> the least.

>

> David

> -------

>

> > -----Original Message-----

> > From: [hidden email] [mailto:concurrency-

> > [hidden email]] On Behalf Of Alex Otenko

> > Sent: Sunday, January 10, 2016 12:04 PM

> > To: Nathan & Ila Reynolds <[hidden email]>

> > Cc: [hidden email]

> > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /

> > Request for Comments

> >

> > I would expect these to be case-specific.

> >

> > The flow of time is different in different frames of reference. Mailer wants

> it

> > to be tied to the frame of reference coinciding with mail server (which is in

> > the same frame as Greenwich), Sudoku game wants it tied to the frame of

> > reference coinciding with Sudoku process space - it doesn?t want to count

> > time towards the score whilst the game is not in the foreground.

> >

> > It would be nice to have a replaceable clock, or the source of time for

> > individual condvars.

> >

> > Alex

> >

> > > On 9 Jan 2016, at 17:18, Nathan & Ila Reynolds <[hidden email]>

> > wrote:

> > >

> > > Also, Windows fires an event to all applications when the system

> resumes

> > after hibernation.  You could use that event instead of polling.

> > >

> > > ScheduledExecutorService provides schedule(), scheduleAtFixedRate()

> and

> > scheduleWithFixedDelay().  I expect schedule() to run the command at or

> > very soon after the delay or as soon as the machine resumes if the delay

> has

> > elapsed.  I expect scheduleAtFixedRate() to run the command N times

> > rapidly if hibernation lasted N periods.  I expect scheduleWithFixedDelay()

> to

> > run the command one time at or very soon after the delay or as soon as the

> > machine resumes.  In this regard, the programmer has control whether

> they

> > need N times or 1 time after hibernation.  I only use scheduleAtFixedRate()

> if

> > I have something staying in sync with the passage of time.  I use

> > scheduleWithFixedDelay() in all other cases because if the command takes

> a

> > long time, I don't need it to run right away.

> > >

> > >

> >

> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ScheduledE

> > xecutorService.html

> > >

> > > -Nathan

> > >

> > > -----Original Message-----

> > > From: [hidden email]

> [mailto:concurrency-

> > [hidden email]] On Behalf Of Markus KARG

> > > Sent: Saturday, January 09, 2016 6:58 AM

> > > To: 'Carsten Schipke' <[hidden email]>

> > > Cc: [hidden email]

> > > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /

> > Request for Comments

> > >

> > > Carsten,

> > >

> > > the Windows API provides several different methods for timing. Some of

> > them are definitively able to fire at a particular point in time, independent

> of

> > any hibernation.

> > >

> > > In case a different OS won't have such a factility, there is a simple fallback:

> > Triggering events more often, checking the actual time (in pure Java), so

> we

> > find out whether to wait further, or whether the event is to be fired. This,

> > BTW, is the workaround applied by pure Java solutions currently, hence

> what

> > I'd like to get rid off by this feature request. :-)

> > >

> > > -Markus

> > >

> > >

> > > -----Original Message-----

> > > From: Carsten Schipke [mailto:[hidden email]]

> > > Sent: Samstag, 9. Januar 2016 14:09

> > > To: Markus KARG

> > > Cc: [hidden email]

> > > Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /

> > Request for Comments

> > >

> > > sure, as I mentioned, I have never really had that requirement, it just

> > sounded to me like many programmers could have many slightly different

> > requirements on such an API. I also don?t know what the Windows API

> > offers in those regards / how its solved there, but if there is such a widely

> > accepted solution, then it surely would make sense as you say.

> > >

> > >

> > >> On Jan 9, 2016, at 21:04, Markus KARG <[hidden email]>

> > wrote:

> > >>

> > >> I think it should be up to the programmer (e. g. by passing a flag or using

> > different methods) whether he wants 10 events after missing those while

> > hibernation, or whether he wants the events to be collapsed into one

> single

> > event alternatively. BTW, I never said that the API must support an

> absolute

> > variant of repeated event schedulung. You could also simply provide an

> > absolute variant of the "fire ONCE" method, and the mail application has to

> > reschedule inside of the event handler.

> > >>

> > >> Hooks are out of scope for my proposal, as they solve a different

> problem

> > and are working on a deeper level (the scheduler API could certainly make

> > use of such hooks). In case the Windows API for example would be able to

> > solve the problem for us (it is, BTW), why shouldn't we provide a Java API

> > wrapping that (without running into any rattail, as we simply offload)?

> > >>

> > >> -Markus

> > >>

> > >> -----Original Message-----

> > >> From: Carsten Schipke [mailto:[hidden email]]

> > >> Sent: Samstag, 9. Januar 2016 11:02

> > >> To: Markus KARG

> > >> Cc: [hidden email]

> > >> Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling /

> > Request for Comments

> > >>

> > >> ?...or it will fire instantly after the end of hibernation ?? considering your

> > example of hourly/periodically checking mails, that would mean that the

> > program checks your mailbox 10 times at once after 10h hibernation.

> > >> So the API would also need to know whether unfired events should

> > queue up over time. Sounds like a rattail pulling endlessly use cases &

> > requirements behind it.

> > >>

> > >> I for one never thought about using the JVM to schedule things that live

> > through hibernation or similar (not knowing the original intention of the

> API).

> > But I have also never built daemon-like desktop/client

> applications/services.

> > >>

> > >> I guess in case of JVM, one could argue that specifications only apply at

> > runtime, and hibernation is interrupting that. Maybe it would be better to

> > provide hooks e.g. in the Runtime class to allow callbacks on pre-/post-

> > hibernation, standby, signals etc. Then one could de/attach events

> > accordingly.

> > >>

> > >>

> > >>> On Jan 9, 2016, at 17:28, Markus KARG <[hidden email]>

> > wrote:

> > >>>

> > >>> The following requests comments on a Feature Proposal for Absolute

> > Scheduling.

> > >>>

> > >>> OpenJDK ticket JDK-8146527

> > (https://bugs.openjdk.java.net/browse/JDK-8146527) describes the

> > following case:

> > >>>

> > >>> * ScheduledExecutorService.schedule() is invoked to schedule firing of

> > an event "in one minute".

> > >>> * The laptop lid gets closed instantly after that, so hibernation will

> occur,

> > hence the JVM will suspend.

> > >>> * After thirty seconds of hibernation, the laptop lid gets openen, so

> > hibernation will cancel and the JVM resumes.

> > >>> * Despite the expected result (one minute after start of program the

> > event does occur), the event actually is delayed by the length of the

> > hibernation phase, and happens 90 seconds after the program was started.

> > In the expectation of the end user, the event fired 30 seconds "too late"!

> > >>>

> > >>> This is annoying to users and rather unexpected and astonishing for

> > programmers literally following the words of the JavaDocs. Clearly the

> > provided deadline is a relative value in the physical sense ("one minute

> from

> > now, independent of what 'now' is currently like"), but certainly what the

> > user actually expects it to work like is an absolute value in the physical

> sense

> > ("one minute from now, where 'now' is the current point on the time axis

> of

> > the Universe, hence unaffected by hibernation). Whether or not the

> laptop

> > was closed temporarily in the meantime plays no role to the expectation of

> > neither the end user nor the application provider.

> > >>>

> > >>> Unfortunately there is no other API that allows the application vendor

> to

> > define that the deadline it meant to be unaffected of hibernation. Clearly

> > this is a drawback to the Java platform, as many applications need such a

> > behaviour (like "check my mails once per hour" - if you open your laptop lid

> > ONLY for a few minutes to see whether meanwhile new emails arrived or

> not

> > [like, BTW, some laptops are able to perform these days, even with the lid

> > closed, thanks to a BIOS timer] you won't receive any new emails ever as

> > "JVM" time progresses only be few minutes per day then).

> > >>>

> > >>> A solution could be the addition of a special variant of

> > ScheduledExecutorService.schedule(absoluteInstant) which is unaffected

> of

> > any hibernation, and will fire either exactly at the absoluteInstant (in case

> the

> > laptop is not hibernating _currently_), or it will fire instantly after the end

> of

> > hibernation, in case the laptop was hibernating at absoluteInstant.

> > >>>

> > >>> There are two possible ways to reach this: Either there is an OS-specific

> > API that alrady provides exactly that behaviour, or the JVM needs to be

> > informed every 'x' fractions of "discontinuous jvm time" to find out how

> > much "continuous real world time" has advanced and whether a scheduled

> > event was missed meanwhile (which is the workaround such applications

> > have to perform on their own currently to workaround the problem). The

> > first is problematic due to changes in the implementations of the APIs (e. g.

> > Windows changed some APIs from "continuous time" to using

> > "discontinuous time"), the second is complex in finding the optimal value of

> > 'x' (too low means high power consumption, too high means firing too late

> > after the deadline).

> > >>>

> > >>> Side note: To be unambiguous, the new deadline should possibly be

> > typed as java.time.Instant, as that could never be misunderstood as

> > "discontinous jvm time" inherently.

> > >>>

> > >>> What is your opinion on that?

> > >>>

> > >>> -Markus

> > >>> _______________________________________________

> > >>> Concurrency-interest mailing list

> > >>> [hidden email]

> > >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

> > >>

> > >>

> > >

> > >

> > >

> > > _______________________________________________

> > > Concurrency-interest mailing list

> > > [hidden email]

> > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

> > >

> > >

> > > _______________________________________________

> > > Concurrency-interest mailing list

> > > [hidden email]

> > > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

> >

> >

> > _______________________________________________

> > Concurrency-interest mailing list

> > [hidden email]

> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

>

>

> _______________________________________________

> Concurrency-interest mailing list

> [hidden email]

> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

>

>

> _______________________________________________

> Concurrency-interest mailing list

> [hidden email]

> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 

 

_______________________________________________

Concurrency-interest mailing list

[hidden email]

http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Requestfor Comments

Timo Kinnunen
In reply to this post by Martin Buchholz-3

Hi,

 

Well it also depends on which function we are talking about. If it is the WaitForSingleObject function then this has apparently changed from Windows 8 onwards, according to MSDN:

 

Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2:  The dwMilliseconds value does include time spent in low-power states. For example, the timeout does keep counting down while the computer is asleep.

 

Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview:  The dwMilliseconds value does not include time spent in low-power states. For example, the timeout does not keep counting down while the computer is asleep.

I haven’t looked at how Object.wait(long) is implemented but if it is using WaitForSingleObject (or the same clock it uses) then it too may be affected. The API documentation promises that one condition for resuming is that “The specified amount of real time has elapsed, more or less”, referring to the specified timeout parameter. So while sleeping a total 90 seconds when only 60 seconds was specified might still be technically within the specification, it’s really pushing it.

 






--
Have a nice day,
Timo

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Tuesday, January 12, 2016 20:09
To: [hidden email]
Cc: [hidden email]
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling / Requestfor Comments

 

On Tue, Jan 12, 2016 at 4:10 AM, Doug Lea <[hidden email]> wrote:

 

> The Right Thing should also be compatible with how Android

> deals with deep-sleep etc. See

> http://developer.android.com/reference/android/os/SystemClock.html

 

TIL about CLOCK_BOOTTIME

http://stackoverflow.com/questions/6360210/androidlinux-uptime-using-clock-monotonic/6360726#6360726

So this is much messier and harder to fix - it's not just a windows bug!

Windows and Linux actually agree!  Both stop the clock while the

system is suspended.

_______________________________________________

Concurrency-interest mailing list

[hidden email]

http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling / Requestfor Comments

David Holmes-6

Thanks for that info Timo, I hadn’t  seen that - we use WaitForMultipleObjects in the VM for everything (there is an event for interruption and an event for actually “parking” the thread),and its MSDN page says nothing about this – which is very odd because the two functions should behave the same. It is interesting to see that MS is moving away from having these core API functions continue to track time across “sleep” states.

 

David

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Timo Kinnunen
Sent: Wednesday, January 20, 2016 3:51 AM
To: Martin Buchholz <[hidden email]>; Doug Lea <[hidden email]>
Cc: concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling / Requestfor Comments

 

Hi,

 

Well it also depends on which function we are talking about. If it is the WaitForSingleObject function then this has apparently changed from Windows 8 onwards, according to MSDN:

 

Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2:  The dwMilliseconds value does include time spent in low-power states. For example, the timeout does keep counting down while the computer is asleep.

 

Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview:  The dwMilliseconds value does not include time spent in low-power states. For example, the timeout does not keep counting down while the computer is asleep.

 

I haven’t looked at how Object.wait(long) is implemented but if it is using WaitForSingleObject (or the same clock it uses) then it too may be affected. The API documentation promises that one condition for resuming is that “The specified amount of real time has elapsed, more or less”, referring to the specified timeout parameter. So while sleeping a total 90 seconds when only 60 seconds was specified might still be technically within the specification, it’s really pushing it.

 






--
Have a nice day,
Timo

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Tuesday, January 12, 2016 20:09
To: [hidden email]
Cc: [hidden email]
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling / Requestfor Comments

 

On Tue, Jan 12, 2016 at 4:10 AM, Doug Lea <[hidden email]> wrote:

 

> The Right Thing should also be compatible with how Android

> deals with deep-sleep etc. See

> http://developer.android.com/reference/android/os/SystemClock.html

 

TIL about CLOCK_BOOTTIME

http://stackoverflow.com/questions/6360210/androidlinux-uptime-using-clock-monotonic/6360726#6360726

So this is much messier and harder to fix - it's not just a windows bug!

Windows and Linux actually agree!  Both stop the clock while the

system is suspended.

_______________________________________________

Concurrency-interest mailing list

[hidden email]

http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: JDK-8146527: Absolute Scheduling /Requestfor Comments

Timo Kinnunen

It is a bit odd but I think it’s because it’s a corner case and also because it isn’t technically a change in the wait functions. If you read them carefully, the timeout interval is given in milliseconds but the actual wait time is defined in terms of ‘ticks’; and the change is in how many ticks occur while the system is sleeping. The millisecond parameter is only for convenience and intuitiveness when deciding how many ticks to wait until the timeout will have elapsed.

 

 

I think for the scheduling issue, the function you’d want would be SetWaitableTimer with relative times converted to absolute UTC time. That way changes to the system clock should get reflected in the timer waiting times automatically. In addition, setting the resume parameter should bring up the system back from power conservation states – provided the system has support for this -- if the timer expiration time ends up occurring during sleep.

 






--
Have a nice day,
Timo

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Tuesday, January 19, 2016 21:27
To: [hidden email]; [hidden email]; [hidden email]
Cc: [hidden email]
Subject: RE: [concurrency-interest] JDK-8146527: Absolute Scheduling /Requestfor Comments

 

Thanks for that info Timo, I hadn’t  seen that - we use WaitForMultipleObjects in the VM for everything (there is an event for interruption and an event for actually “parking” the thread),and its MSDN page says nothing about this – which is very odd because the two functions should behave the same. It is interesting to see that MS is moving away from having these core API functions continue to track time across “sleep” states.

 

David

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Timo Kinnunen
Sent: Wednesday, January 20, 2016 3:51 AM
To: Martin Buchholz <[hidden email]>; Doug Lea <[hidden email]>
Cc: concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling / Requestfor Comments

 

Hi,

 

Well it also depends on which function we are talking about. If it is the WaitForSingleObject function then this has apparently changed from Windows 8 onwards, according to MSDN:

 

Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2:  The dwMilliseconds value does include time spent in low-power states. For example, the timeout does keep counting down while the computer is asleep.

 

Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 Technical Preview:  The dwMilliseconds value does not include time spent in low-power states. For example, the timeout does not keep counting down while the computer is asleep.

 

I haven’t looked at how Object.wait(long) is implemented but if it is using WaitForSingleObject (or the same clock it uses) then it too may be affected. The API documentation promises that one condition for resuming is that “The specified amount of real time has elapsed, more or less”, referring to the specified timeout parameter. So while sleeping a total 90 seconds when only 60 seconds was specified might still be technically within the specification, it’s really pushing it.

 






--
Have a nice day,
Timo

Sent from Mail for Windows 10

 

From: [hidden email]
Sent: Tuesday, January 12, 2016 20:09
To: [hidden email]
Cc: [hidden email]
Subject: Re: [concurrency-interest] JDK-8146527: Absolute Scheduling / Requestfor Comments

 

On Tue, Jan 12, 2016 at 4:10 AM, Doug Lea <[hidden email]> wrote:

 

> The Right Thing should also be compatible with how Android

> deals with deep-sleep etc. See

> http://developer.android.com/reference/android/os/SystemClock.html

 

TIL about CLOCK_BOOTTIME

http://stackoverflow.com/questions/6360210/androidlinux-uptime-using-clock-monotonic/6360726#6360726

So this is much messier and harder to fix - it's not just a windows bug!

Windows and Linux actually agree!  Both stop the clock while the

system is suspended.

_______________________________________________

Concurrency-interest mailing list

[hidden email]

http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
12