(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
