concurrency (was Re: important news: refocusing discussion)

[John Meacham]

On Tue, Mar 28, 2006 at 11:05:03AM +0100, Malcolm Wallace wrote:
> I was misled by several people's hand-waving assertion that, provided
> you used MVars "correctly", there would be no synchronisation problems.
> But no-one had yet defined what "correct" meant.  I kind of assumed they
> meant you could write concurrent threaded code (with only some minor
> restrictions) and have it work in a single-threaded implementation
> without change.  This seemed like a pretty strong (and dubious) claim to
> me.

it is true if you omit forkIO. as in, any use of MVars that cannot
dead-lock and doesn't use forkIO in a concurrent setting, can't deadlock
in a non-concurrent one.

it is possible to write programs that only won't deadlock in a
concurrent setting, but _only_ if you explicitly use forkIO at some
point so we still have our static guarentees about deadlocks.


> But now I see you are actually saying something quite different.  (And I
> recall some discussion on these points from a few months ago.)
> 
>   * IORef is inherently thread-unsafe, and so we should eliminate IORefs
>     from the language.

dear golly no. that is part of the point of IORefs, the memory barriers
needed by MVars are _extremely_ expensive compared to the simple memory
accesess that IORefs should encompass, you don't want to use MVars
except when absolutly needed. when using IORefs it is your
responsibility to ensure they are used solely from within a single
thread, the same way it is your responsibility to not deadlock when
using MVars.


>   * One can write single-threaded code using MVars instead of IORefs,
>     and it will be safe on a multi-threaded implementation.

but much much less efficient on multi-threaded systems if you knew the
refs would only be used in a single threaded manner (as is the case for
most uses of iorefs)

We do need to say something about the distinction between IORefs and
MVars in the report, but getting rid of IORefs would be a horrible
mistake if we want our concurrent implementations to be fast. if nothing
else, we lose the intent of the programmer.

I would even go so far as to disallow the IORef protected by MVar usage
model just to be future-safe. but that might be too unpopular and STM
sort of makes it less important to worry about.

        John

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