[Pharo-users] Concurrency Best Practices + Tests

Ben Coman btc at openinworld.com
Thu Sep 5 00:30:36 EDT 2019


On Wed, 4 Sep 2019 at 21:32, Noury Bouraqadi <bouraqadi at 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?
>

I haven't any formalized advice, but just a scattering of thoughts:
- When the debugger opens, it really disturbs the timing context between
threads, so the problem you are looking for disappears.
- Tracking down timing-related problems often required interleaved-threads
logging to a threadsafe queue so a historical sequence could be reviewed.
   Sometimes this included exporting it to Excel then manually chopping
repeating sectioning into side-by-side columns to see how the order of
execution differs between cycles.
- Correctly distinguish between your "shared resource" problems and your
"work signalling" producer/consumer problems, respectively using mutexes
and semaphores.
   I think the latter is easier to reason about.

btw, watch out for Announcements.  You will appear to register them for the
receiving-thread, but actually they are executed in the context of the
sending-thread.


- How to discover need for synchronization/critical sections/ when doing
> TDD?
>

First consider whether synchronisation can be avoided using queues with
"positive hand-off"
 http://www.flounder.com/no_synchronization.htm

This video I bumped into today touches on the same thing...
https://www.youtube.com/watch?v=2yXtZ8x7TXw

Not available right now, but along the line "apartment-threading" I have
been musing about VM support for "Process-specific-immutability"
So an object has an "owner-process" which is the only thread able to mutate
it.
The existing immutability flag would be turned on, and when triggered the
VM would check if the thread-id matched before allowing/blocking an update.

For example, in a producer/consumer arrangement there could be a specific
system thread dedicated to processing class/code-modifications
which could keep that safe without scattering mutexes through that code,
but anyone can read it.



One thing that wasn't obvious to me until I read it, was that
lazy-initialization which is common in TDD is problematic with concurrency.
I'm still mulling over the implications, but it seems reasonable that you
can get at least double-initialization.
So its better to initialize at creation time before it is handed around to
other threads.


- How to write code to avoid dead-locks?
>

Here are some bookmarked articles I found enlightening on the differences
between between mutexes and semaphores.
The last two identify typical problems.
1. https://barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore
2.
http://blog.feabhas.com/2009/09/mutex-vs-semaphores-%e2%80%93-part-1-semaphores/
3.
http://blog.feabhas.com/2009/09/mutex-vs-semaphores-%e2%80%93-part-2-the-mutex/
4.
http://blog.feabhas.com/2009/10/mutex-vs-semaphores-%e2%80%93-part-3-final-part-mutual-exclusion-problems/

5. http://www.smxrtos.com/articles/techppr/mutex.htm



You may find some useful patterns in these books...
- http://greenteapress.com/semaphores/LittleBookOfSemaphores.pdf
-
https://pdfs.semanticscholar.org/a51b/40c904add79f590ed887ccd3a78dbe630938.pdf


cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20190905/175e65bc/attachment.html>


More information about the Pharo-users mailing list