Getting locks and sharing: was RE: Getting concurrency

[Alex Arnon]

On 6/21/05, Ulf Wiger (AL/EAB) <ulf.wiger@REDACTED> wrote:
> 
> 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
> 

I see. There is indeed a great advantage to the assumption (apologies,
all :) ) that when using locally-spawned processes, all communication
between them is ensured - design is greatly simplified.