> d. With (2), scheduling determines which of two conflicting
> writers gets to fill an MVar, and the loser simply blocks
> until the MVar is empty again. With (1), however, scheduling
> determines **whether or not there will be an exception**: if a
> reader is scheduled on a filled MVar before the second writer,
> everything is fine, whereas if the second writer is scheduled
> before any readers, you'll have an exception. Such things are
> fun to debug..
Where I come from, that's called a race condition :-) We shouldn't change
the semantics because it's possible to write broken programs using the
existing semantics. The criteria seem to be
1. efficiency
2. functionality
George is saying that we shouldn't compromise (1) at all, even for a gain in
(2). That's fine. However, changing the semantics of putMVar on a full
MVar is unlikely to affect existing programs, since this situation is
already exceptional (and was in fact a fatal error until recently). As far
as the programmer is concerned, (2) is largely redundant because we can
implement pretty much any functionality using MVars as they stand.
Another issue is brought up by distributed execution: at the moment, both
putMVar and takeMVar imply remote synchronisation. Choosing to overwrite an
existing value with putMVar would mean that no synchronisation is required.
> The main reason why I did not speak up before is that the
> original CH paper seemed to suggest that MVars would only be used
> at the most basic implementation level, whereas users and
> libraries would almost certainly use safe variants (e.g., CVars)
> built, in CH, on top of MVars. This would have achieved ease of
> implementation while also protecting users from the dangers of
> (1). Unfortunately, the present discussion of MVar properties
> shows that if a feature is easily accessible, some hackers will
> use it!-)
It turns out that in a large number of cases, the existing MVar semantics is
sufficient (and more efficient than using one of the abstractions).
Cheers,
Simon
