Getting locks and sharing: was RE: Getting concurrency

[Ulf Wiger (AL/EAB)]

Alex Arnon wrote:
>
> Would there be a reason to prefer random discard? I.e., if we 
> rephrase 
>     ...if s2 arrives then s1 is guaranteed to have arrived 
> before it...
>  to 
>     ...if s2 arrives then s1 is guaranteed to have either arrived
> before it or never arrived.
> 
> This would then simulate a congested network, which might be a more
> "generic" way of handling memory-full situations.

Personally, I think this would be unfortunate, because then, you
must add sophistication to your program.

The guarantee that s1 will have been delivered if s2 was delivered,
means e.g. that you can do things like acknowledge every 10th
message in an internal transfer protocol. Then, the sender knows
that all messages to that point have also arrived.

Another given with such a guarantee is the serialization property.
This allows you to reason in a fundamentally different way in
situations where synchronization is important.

An example: In the gen_leader program, I wrote a replicated
dictionary. This implementation is entirely faulty if you
must assume that messages can be arbitrarily dropped,
because you cannot know that all preceding writes were actually
committed to a backup copy, simply because the last one was.
This forfeits the underlying reasoning behind much of gen_leader.
(Which is not _the_ reason why I object -- rather a fairly 
descriptive example of how you might program given the presence
of such guarantees.)

/Uffe