In the Finite State Machines chapter of Learn You Some Erlang, the author uses a pair of :gen_fsm processes to implement a game’s trading system. A lot of effort is spent on avoiding deadlocks and race conditions. I was wondering, would using a single shared :gen_fsm process (between the two involved players) have mitigated some of these problems? I haven’t thought it all the way through yet, and I’m still coming to grips with designing concurrent applications. Can someone more experienced provide some insight?
1 Like
Yes, but I think Fred’s comment says a lot:
The design I have picked is somewhat challenging. Rather than using a broker through which players route items and confirmations (which, frankly, would be easier), we’re going to implement a server where both players speak to each other directly (which would have the advantage of being distributable).
Also a lot of the problems he attacks are critical in designing concurrent systems so it is a good place to address them.
One thing to be aware of is that :gen_fsm is now deprecated in favour of :gen_statem, it will, however, not disappear in the foreseeable future. At this level they are very similar though they differ in details, for example how the state functions are called and what they should return.
5 Likes
