Thanks Vince, Christopher, and Tim! Noury
> On 15 Oct 2019, at 05:46, Vince Refiti <vince.ref...@trapezegroup.com.au> > wrote: > > 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 > <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 > <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 > <mailto: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
