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