Getting locks and sharing: was RE: Getting concurrency

[David Hopwood]

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

The assumption isn't that all communication is ensured; in the case
of two processes it is that the messages received are a prefix of the
messages sent. (More generally, that the messages received are consistent
with causal ordering -- which is easier to use than it is to define.)
You can't really ensure anything stronger than this in an asynchronous
message passing system where processes can fail.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>