On 22/10/2007, Giovanni Corriga giovanni@corriga.net wrote:
Il giorno lun, 22/10/2007 alle 10.49 +0300, Igor Stasenko ha scritto:
On 21/10/2007, Jason Johnson jason.johnson.081@gmail.com wrote:
On 10/21/07, Igor Stasenko siguctua@gmail.com wrote:
If you need to synchronize access to some object you simply can't avoid that - at any level of abstraction (being in Erlang or OS, or assembler).
That's the point: you *don't* have synchronized access to any object. All you have is messages. Think of it as an OO view of processes. You can't see what's inside, you can only ask the process to do things on your behalf.
Again, a question raised: how to ensure that messages are passed in correct order and make sure that messages are delivered? Now lets look inside: to make it working properly, you need to implement a message queue. And queue means that you must make an 'enqueue' and 'dequeue' operations synchronized. And that's exactly what i mean: even if you hide the concurrency problems from the eyes of developer, this is not means that problems are gone: now you have to deal with them by own. If you know another way(s) how to make proper message passing scheme without using synchronized object (such as queue), i am all ears.
The Erlang way: don't care about the order of arrival of the messages, and let the developer care about that when it's important.
Yes, a simple example when i need to have correct order: Collection>>do:
to print an array i'll have all items ordered from start to end , not in random order.
And of course there are cases, when i don't need to have items iterated in specific order. When i simply need to visit all items in collection to send a message to them.
So, we need at least 2 messages to reflect a different behaviour: #do: and #orderedDo:
and that's only the simplest case...
Giovanni