[erlang-questions] Question about message passing paradigm

Erik Reitsma <>
Mon Jun 30 08:45:07 CEST 2008

What about:
4. Send a message to A, containing both the actual request for A, and a
function FA to be executed by A. This function FA will send a message to
B, containing the actual request for A, and a function FB to be executed
by B. This function FB will send a message to C, containing the actual
request for C, and a function FC to be executed by C. This function FC
will send a message to D, containing the actual request for D, and
possibly a function FD that does nothing. All the processes wait for the
answer to their messages, of course. This way, A will not process
anything (and therefore not change state), while waiting for B, which
waits for C, which waits for D. B will not change state while waiting
for C and D, and C will not change state while waiting for D. This is
like locking A, then locking B, then C, then D, then releasing D, C, B
and A.
Beware of cyclic "locks" in this approach!


[mailto:] On Behalf Of Edwin Fine
	Sent: Sunday, June 29, 2008 12:42 PM
	To: Mike T
	Subject: Re: [erlang-questions] Question about message passing
	I'm a bit of an Erlang newbie so the gurus may come up with
something much better than this, but I can think of these possible

	1.	Create a gen_fsm that controls all the collections. The
collections could be ETS tables or gen_servers wrapping ETS tables.
Under normal use, messages are sent to the fsm to update the collections
individually. When the time comes to require consistency across the
collections, send a message to the fsm to get the collective state data.
The fsm goes into a different state while it gathers the data. This
state would reject requests to update the collections (or wait until the
state changes), although reads would still be allowed. On getting the
result, the state changes back to allow updates again. 
	2.	Create a memory-only Mnesia table for each collection,
and use Mnesia transactions to get the multiple values atomically. 
	3.	Change the architecture of the current lock-oriented
program to make better use of Erlang's features.

	Hope this helps.
	2008/6/29 Mike T <>:

		I was not sure where best to post this and hope someone
is able to
		help with this question.
		After being bitten by the pitfalls of lock-oriented
multi threading I
		am interested in switching to message passing oriented
		I have read that erlang has a per-process ordering
guarantee (that is
		if A sends messages 1 and 2 to B 1 will arrive before 2
at B. However,
		there is no guarantee that messages from C and D will
not be placed in
		between 1 and 2.
		So my question is this:
		In my current lock oriented program design I have
threads dedicated to
		managing different collections and actions on those
		(hashmaps), lets call them A, B, C, and D. At several
points in the
		program one thread needs to get data from the other
collections and
		make a decision based on the collective state of the
values it gathers
		form those other collections.
		An example situation would be A needing data from B, C,
and D. In that
		case A would attempt to lock A, B, C, and D then gather
the items it
		needs and release the lock.
		How would I accomplish this same task in a message
passing manner?
		I had though of doing: A sends a message to B, C, and D
asking for the
		data. However, B, C, and D may have each changed
independently of each
		other by the time they receive the request for data
and/or by the time
		they are able to send the message to A. So, how do you
deal with
		situations like this in a message passing paradigm? 
		erlang-questions mailing list

	The great enemy of the truth is very often not the lie --
deliberate, contrived and dishonest, but the myth, persistent,
persuasive, and unrealistic. Belief in myths allows the comfort of
opinion without the discomfort of thought.
	John F. Kennedy 35th president of US 1961-1963 (1917 - 1963) 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080630/f5525e43/attachment.html>

More information about the erlang-questions mailing list