Hello, My answer is late, but hopefully still useful. I'm not a concurrent programmer in Pharo, but have done it in lots of other environments. Use the immutable object pattern to avoid having to deal with race conditions (although it won't solve all the problems). POSA2 was focused on OO concurrency, and had been applied in C++ and Java: http://www.dre.vanderbilt.edu/~schmidt/POSA/POSA2/ <http://www.dre.vanderbilt.edu/~schmidt/POSA/POSA2/> You can find Coursera MOOCs with modern application of the POSA2 patterns, but it's mostly focused on Android. Advice is often to use an environment's thread-safe data structures and thread pool librairies, if they exist. It's a bigger challenge otherwise to create these yourself. I saw a cool exercise of understanding race conditions for the Singleton pattern in the book Head First Design Patterns. It basically looks at breaking up source code of a concurrent method into chunks, and figuring out if you can get a race condition with two threads executing them separately. The metaphor is magnets on a refrigerator door. See the attached image. The Spin model checker (using a DSL, called PROMELA, for code modeling) works in a similar way, by creating all possible executions and checking for violations of invariants. But that's a formal method that is hard to apply to arbitrary (complex) code. Cheers, Cris On Wed, Sep 4, 2019, 09:32 Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi everyone,
Can I get your input on the following questions :
- What are your best practices and recommendations for developing and testing concurrent software?
- How to discover need for synchronization/critical sections/ when doing TDD?
- How to write code to avoid dead-locks?
Noury
