concurrency guarentees clarification

John Meacham john at repetae.net
Mon Apr 24 19:03:19 EDT 2006


I have been twiddling some with the wording of the concurrency
guarentees and want to run them by the list.


the rules I am thinking of adding are:

* every runnable thread is guarenteed to run in a finite amount of time if a
  program reaches a yield-point infinitly often.

* Foreign concurrent calls, handle IO, and all IO actions that directly
  interact with the world outside the current process all must be
  yield-points. (in addition to any yield-points implied by the progress
  guarentee)

The first rule is just to rule out completely brain-dead schedulers and
give a fairly useful fairness guarentee. (in fact, I think it subsumes
the preemptive fairness guarentee as written, as a preemptive
implementation does reach a yield-point infinitly often independently of
what the program is doing)

I originally thought the progress guarentee implied the second, but I
realize that is somewhat UNIX-centric in that all IO must be treated as
potentially blocking. however in an embedded system where for instance
you write directly to the screen buffer rather than a file descriptor
this might not be the case so we should probably be more clear.

I would like to avoid enumerating the yield points explcitly, except
perhaps as a guide saying "these library routines are examples of those
in the standard library that must be yield-points according to the
standard". Coming up with a rule rather than a list will make it easier
for users to think about and give guidance (though of course we can't
guarentee) where yield-points should be placed in any implementation
provided extensions.


I don't intend to imply things like all memory access in case it is in
an memory mapped IO region or anything that changes CPU load because
someone might be looking at your CPU usage in /proc should be
yield-points, just those IO actions that "explicitly" interact with the
outside world. for the correct definition of explicitly. :)

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈


More information about the Haskell-prime mailing list