I’d love to see someone write a recording debugger for smalltalk. In theory you might be able to use rr with Pharo.
https://rr-project.org/ ../Dave On Oct 15, 2019, 9:22 AM -0400, Noury Bouraqadi <bouraq...@gmail.com>, wrote: > 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) 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/ > > > > 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> 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 >
