On 22/10/2007, Sebastian Sastre ssastre@seaswork.com wrote:
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.
-- Best regards, Igor Stasenko AKA sig.
- For the correct order: I understand that Erlang is open so, to some
point, nothing stop us from looking that how-tos on how Erlang's VM makes the message passing in correct order right? Seems to me that somehow they solved that question and probably we can study how assimilate that virtue.
While reading this topic, i googled, just to look what solutions are found in this area for non-locking queues. There is no wonder (still) - they all based on atomic CaS (Compare and Store) processor instructions. Its of course interesting how Erlang manages message passing, but i doubt that it based on something much different.
- For ensuring messages sends: "send and pray"
That way when a smalltalk's erlangized message send is in a process that terminates it should end with some cause for the act of finish. Maybe this will allow for instance to implement DNU: the VM don't find a proper method in the object to receive that message so it terminates the process stating that as cause.
An 'erlangenization' of sends mean that we need deal differently with contexts. I think best way for this, is to rethink a context to make it look closer to what is a process in Erlang. Yes, we must pay the price of making all contexts be real objects for each message send, so we might expect a real slow-down of single thread execution. Then the only way how we could regain this loss is to use highly parallelisable algorithms.
Cheers,
Sebastian