I can definitely second all the points. If you want to verify your design formally, Vereofy (http://www.vereofy.de) is another model checker that focuses on communication and coordination.
Best, Steffen Am .10.2019, 08:49 Uhr, schrieb Richard O'Keefe <rao...@gmail.com>:
(1) Be very clear in your design about which objects are shared and which are not. (2) Immutable objects can be shared safely. Mutable ones are much much harder to work with. (3) Lazy initialisation does not work well in concurrent programming, *except* when you are constructing an immutable value and it doesn't matter if the variable is initialised twice. (4) If you can possibly do so, *SEPARATE* the concurrency structure from the application- specific work. Use something like Promela/SPIN, or NuSMV, or NuXmv, to check your concurrency structure, or CPN Tools if you prefer Coloured Petri Nets as a modelling notation. This is what Erlang does with great success with "behaviours"; the concurrency structures are there in the library and you just plug in the non-concurrent part. Look up "parallelism patterns" and "algorithmic skeletons". The book https://pdfs.semanticscholar.org/f43e/7c6a40b96743f2217472a49cd616622bdc26.pdf may be helpful. Separation of concerns: this way you can test the concurrency structure of your code independently of the rest. (5) It isn't clear to me that TDD is a good way to develop concurrent programs. It's a great way to develop the non-concurrent *parts*. One reason I say this is that I've found that it is better to avoid adding unneeded sequencing in a design than to add concurrency to a sequential code. If you try to *add* critical sections in a language like Lisp or Smalltalk, you *will* miss some. So the TDD Way of is likely to seduce you into making your code too sequential too soon. (6) I personally find processes communicating via SharedQueues *much* easier to design and make work than processes communicating via shared variables and mutexes or semaphores. (Basically, a Semaphore is a SharedQueue that can only remember how many items it's holding, not what they were.) Your experience may be different, but Processes with private data communicating via SharedQueues transfer much easier to concurrent activities on separate machines communicating via sockets. On Thu, 5 Sep 2019 at 01: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
