On 18.11.2011 19:42, Patrick Logan wrote:
Hi Oliver, Is it fair to say an Akka-based program should be free of deadlock and race conditions? They will show up in different ways, but will easily show up without a design that attempts to eliminate them. (Same with starvation, which can show up in STM at a lower level, but maybe more likely at a high level with distributed actors.)
This is actually a bit confusing for me. In general actors only communicate with other actors through exchange of asynchronous messages. These messages are queued by the receiving actor where they are processed by a single thread in a sequential order. This way there are no locks, no threads can be waiting for a lock and no deadlocks may occur. This is on the positive side of actors. On the negative side there are all the inherent problems incurred by asynchronous programming. So there is a trade-off and people have to make up their mind whether their problem can be solved well by the actor model or not. Then I was referring to actors in combination with STM in general. Maybe I should have pointed out better that I was not specifically into Akka. Nevertheless, there is a problem with message sends between actors becoming circular and running in an endless loop. Often caused when exception handlers get invoked which cause messages send scenarios to happen that have not been tested that excessively as the big use cases people concentrate on. In the old times with Smalltalk not being preemptive somewhen you realized that performance has gone down and then you start looking for the reason. Nowadays, with scheduling in Smalltalk, Java, etc. being preemptive responsiveness will not drop that sharply. So it might take more time till somewhen someone realizes that there is a problem with circular message sends (should be easier detectable than deadlocks because of committing database transactions). I have spent several years reproducing deadlocks and race conditions and fixing them when working on a shop floor control system. The customer gets definitely mad at you when production in some factory is down, because of a deadlock or race condition. In that shop floor control system every machine runs on its own. It will not wait till the server has consumed some notification. Time is money ... Therefore communication was asynchronous and on the server-side there was a thread of its own serving a specific machine in the system. Then when I read about actors a while ago I realized how well they would have fit into the programming model of that shop floor control system. This is where my interest in lock-free concurrent programming with actors comes from. It is not about messing around with actors because they are hip at the moment. There was a big drop in the number of deadlocks back then when I replaced all locks by read-write-locks. This is why I like the idea in STM that a write is either successful or an optimistic locking exception is thrown. The minimal performance loss when retrying the unit of work till the write succeeds is really almost nothing compared to production in some factory coming to a standstill because of a deadlock. Therefore I was thinking aloud whether adding optimistic locking to JavaSpaces would be considered beneficial. Regards, Oliver
I think Akka could mature into a useful system, but it lags Jini in significant ways... which is really the point of my original question, why not go back to Jini and bring it forward in the Scala world as well as the Java world. Also perhaps introducing optimistic locking and STM in new kinds of Jini-based services would have some applications. For example, rather than trying to augment Javaspaces with these mechanisms, they may be better applied to a shared, mutable data(base)(-ish) kind of service.
