Hi Q. What are your best practices and recommendations for developing and testing concurrent software? A. I avoid writing concurrent code if I can. If not, I would launch multiple Smalltalk instances instead.
Even then I would use SQLite3 (or even Postgres, Redis etc) to hold the shared mutable state. SQlite3 locks the db for writes, which is exactly the behaviour I need to controlled access. SQlite3 and Redis can be in memory and can be very fast. I use UDBCSQLite3, but looking at Sven’s SimpleRedisClient (https://github.com/svenvc/SimpleRedisClient) out of sheer curiosity. Then, I can just write sequential code without worrying too much about race/starvation conditions. If not then it class-side mutexes and semaphores, but only as a last resort. Q. How to discover need for synchronization/critical sections/ when doing TDD? A. I do the opposite. I make everything critical, and instead look for places where I can do Process yield. Brutal, but effective. Q. How to write code to avoid dead-locks? A. Use SQLite3 to hold shared mutable resources. It locks the entire db for writes, solving the deadlock for me. I will give SimpleRedisClient a run sometime. Vince From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of Christopher Fuhrman Sent: Tuesday, 15 October 2019 11:39 AM To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] Concurrency Best Practices + Tests EXTERNAL: Do not click links or open attachments if you do not recognize the sender. 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/<https://urldefense.com/v3/__http:/www.dre.vanderbilt.edu/*schmidt/POSA/POSA2/__;fg!09EJrJkydGw!RZmj5IufCu5nBi1-U1FHb6CpYodkamBVuIYPrJLsQ3RGIaDU5FpZeJftWaDoHGXSAoge9Uoe5w$> 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 <bouraq...@gmail.com<mailto:bouraq...@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
