Various models of concurrency exist and the most common and/or praised are:
- 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.
- 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
- 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