Sun Aug 8 19:06:23 CEST 1999
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.
On 5 Aug 1999, Luke Gorrie wrote:
luke>I'm wondering if someone can help me with a pattern for avoiding a
luke>deadlock. Fundamentally, my problem is this:
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>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>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!
Ulf Wiger, Chief Designer AXD 301 <>
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
More information about the erlang-questions