threads - use them as much as you can
Tue Nov 28 13:29:13 CET 2000
Samuel Tardieu <> writes:
> At the beginning of OO programming, programmers were told "Look, it is
> so nice, you do not call subprograms, you send messages to objects which
> will then react to those messages". This view was flawed, as the object
> was not reacting at all (it had no thread of control on its own), it just
> provided the caller with what to do (the method's code).
Somewhere between the two, Eiffel has (at least on paper) a really
interesting CSP-like way of doing communication. I can't help but talk
about it every time concurrency comes up.
IIRC, you have some nodes (I think Eiffel calls them CPUs), and each
object belongs to one of them. A node (like an Erlang process) is a
single thread of execution which is shared by the objects it
Suppose you're an object. When you call a method on another object
that's node-local, you jump into its code directly. But: when you call
a method on a remote object, you essentially send a message to it
asking for the method to run, and block waiting for a reply. On the
receiver's end, it accepts the message only when a) the preconditions
of the method are met, and b) the node isn't busy running some other
method. The fun bit is (a), because if for instance you call the 'get'
method of a queue object, it might have a precondition like "not
empty", meaning that your call will block until there's something on
the queue for you to get - just the same sort of lovely CSP-style
implied synchronization you get with guarded receives in Erlang.
Most significantly perhaps, it avoids the big problem in Java of
having multiple threads mucking with the same objects at the same time
- IMO the essential thing that makes java concurrency so hard.
They also do clever stuff with lazy synchronization of nodes. You can
asynchronously fire off some side-effect-only methods, and then
automatically block until they finish the next time you query some
state from an object on the node.
I've never used an Eiffel that implemented this "SCOOP" concurrency,
so I dunno if it actually works. That keeps me very curious - an
excellent implementation strategy for a niche language!
Thank you for your patience :-)
More information about the erlang-questions