lundi 2 février 2015

What are some good "and" bad use cases for concurrency models like threading, actors and STM (Software Transactional Memory)?


Various models of concurrency exist and the most common and/or praised are:



  1. Threading - classical model. Manually need to handle locks and synchronization and deal with shared memory. For the sake of argument let's put "monitors" in this class, for enforcing mutual exclusion.

  2. Actors: Shared nothing concurrent 'processes' (for the lack of a better word). Good for isolation and concurrency but not so go good for synchronization - seems you need to develop custom "messages" on top of this to get what you want. But seems like that'd be 'natural' since all you can do is send/receive messages

  3. STM - making shared pieces of code accessible via 'transactional' logic. Similar to DB transactions with optimistic commits. Of course, how to handle failures/retries has to be accounted for and may or may not suffer from the same problems as DB transactions. They help enforce concurrency via inbuilt mechanisms of synchronization and have a notion of shared state unlike actors.


Given these models of concurrency, as a software engineer/designer/architect, which model is the most appropriate for which type of scenarios? When should I choose one over the other? What would be some good use-cases - both good and bad for each of the models above.


For example: The use-case of transferring money is great for STMs but bad for actors, since the you really need a transaction of atomic withdraw and deposit functions. With actors you really have to custom develop your protocol to do this. You could do this with threading/locking too but gets tricky quickly.


This is a simple cut-and-dry scenario. What are some others that you've encountered when developing large scale systems that would throw more light on when is one better than the other?


I'm sure a hybrid approach is always better but certain languages/frameworks only support one and not the other. What all should one factor into their decision of the concurrency model to use when writing highly concurrent and/or parallel applications?





Aucun commentaire:

Enregistrer un commentaire