Concurrency Best Practices + Tests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Concurrency Best Practices + Tests

N. Bouraqadi
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
Reply | Threaded
Open this post in threaded view
|

Re: Concurrency Best Practices + Tests

Ben Coman


On Wed, 4 Sep 2019 at 21:32, Noury Bouraqadi <[hidden email]> 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"
 
This video I bumped into today touches on the same thing...

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.  



You may find some useful patterns in these books...

cheers -ben