Concurrency problem

[Ulf Wiger]

One solution that I sometimes use is to store state data in ETS.
Say, for example (don't know if this fits your particular problem) that
A wants to make a "write" request to B, and B in the process wants to make
a "read" request to A, this can be solved by A storing readable values 
in a public or protected ETS table. This way, B can make a non-blocking
request and avoid deadlock.

To avoid creating a race condition instead, one should take case not to 
write to the ETS table from more than one process.

/Uffe

On 5 Aug 1999, Luke Gorrie wrote:

luke>Hi all,
luke>
luke>I'm wondering if someone can help me with a pattern for avoiding a
luke>deadlock.  Fundamentally, my problem is this:
luke>
luke>I have two gen_server processes, A and B.  A wants to make a call on
luke>B for the sake of the side-effects.  These side-effects involve making 
luke>calls to A.
luke>
luke>So, it seems to me that if A makes a gen_server:call to B, then when B 
luke>does the same back to A, it will get a cycle in the call graph and
luke>deadlock.  Now, it might seem that it's the inappropriate use of
luke>side-effects that's the problem, and that B should just return a value 
luke>for A to use, however I'm trying to follow an explicit mapping which
luke>has things this way.  Specifically, a corba Portable Object Adapter
luke>calling an AdapterActivator.
luke>
luke>Any help would be appreciated.  Infact, I'd love to some general
luke>information about managing things with Erlang's concurrency model, I'm 
luke>sure there are oodles of useful patterns - pointers would be great!
luke>
luke>Cheers,
luke>Luke
luke>
luke>
luke>

Ulf Wiger, Chief Designer AXD 301      <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuvägen 9, Älvsjö                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44