<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1611" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=475163606-30062008><FONT face=Arial color=#0000ff size=2>What 
about:</FONT></SPAN></DIV>
<DIV><SPAN class=475163606-30062008><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=475163606-30062008><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=475163606-30062008><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=475163606-30062008><FONT face=Arial color=#0000ff size=2>Beware 
of cyclic "locks" in this approach!</FONT></SPAN></DIV>
<DIV><SPAN class=475163606-30062008><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=475163606-30062008><FONT face=Arial color=#0000ff 
size=2>*Erik.</FONT></SPAN></DIV>
<DIV><SPAN class=475163606-30062008><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> erlang-questions-bounces@erlang.org 
  [mailto:erlang-questions-bounces@erlang.org] <B>On Behalf Of </B>Edwin 
  Fine<BR><B>Sent:</B> Sunday, June 29, 2008 12:42 PM<BR><B>To:</B> Mike 
  T<BR><B>Cc:</B> erlang-questions@erlang.org<BR><B>Subject:</B> Re: 
  [erlang-questions] Question about message passing 
paradigm<BR></FONT><BR></DIV>
  <DIV></DIV>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 
  approaches:<BR>
  <OL>
    <LI>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. 
    <LI>Create a memory-only Mnesia table for each collection, and use Mnesia 
    transactions to get the multiple values atomically.
    <LI>Change the architecture of the current lock-oriented program to make 
    better use of Erlang's features.<BR></LI></OL>Hope this helps.<BR><BR>
  <DIV class=gmail_quote>2008/6/29 Mike T <<A 
  href="mailto:talmage.news@gmail.com">talmage.news@gmail.com</A>>:<BR>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Hello,<BR><BR>I 
    was not sure where best to post this and hope someone is able to<BR>help 
    with this question.<BR><BR>After being bitten by the pitfalls of 
    lock-oriented multi threading I<BR>am interested in switching to message 
    passing oriented concurrency.<BR><BR>I have read that erlang has a 
    per-process ordering guarantee (that is<BR>if A sends messages 1 and 2 to B 
    1 will arrive before 2 at B. However,<BR>there is no guarantee that messages 
    from C and D will not be placed in<BR>between 1 and 2.<BR><BR>So my question 
    is this:<BR>In my current lock oriented program design I have threads 
    dedicated to<BR>managing different collections and actions on those 
    collections<BR>(hashmaps), lets call them A, B, C, and D. At several points 
    in the<BR>program one thread needs to get data from the other collections 
    and<BR>make a decision based on the collective state of the values it 
    gathers<BR>form those other collections.<BR><BR>An example situation would 
    be A needing data from B, C, and D. In that<BR>case A would attempt to lock 
    A, B, C, and D then gather the items it<BR>needs and release the 
    lock.<BR><BR>How would I accomplish this same task in a message passing 
    manner?<BR><BR>I had though of doing: A sends a message to B, C, and D 
    asking for the<BR>data. However, B, C, and D may have each changed 
    independently of each<BR>other by the time they receive the request for data 
    and/or by the time<BR>they are able to send the message to A. So, how do you 
    deal with<BR>situations like this in a message passing paradigm? 
    <BR>_______________________________________________<BR>erlang-questions 
    mailing list<BR><A 
    href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</A><BR><A 
    href="http://www.erlang.org/mailman/listinfo/erlang-questions" 
    target=_blank>http://www.erlang.org/mailman/listinfo/erlang-questions</A><BR></BLOCKQUOTE></DIV><BR><BR 
  clear=all><BR>-- <BR>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.<BR>John F. Kennedy 35th president of US 1961-1963 (1917 
  - 1963) </BLOCKQUOTE></BODY></HTML>