Not to sound flippant - but do everything you can to limit where you use concurrency (and if possible, not at all). It adds lots of complication that often isn���t necessary.

Where you do need it, queue results or commands and then have workers to process those - workers, queues and commands put you back into easily testable territory.

Then you are left with the concurrent bit - hopefully now quite tiny and specific, which you you can normally blast and test if you have concurrency hole - but in the realms of can it queue things up in an orderly fashion and dequeue them as well. Deep code inspection on this is also helpful (albeit manual).

Tim

Sent from my iPhone

On 4 Sep 2019, at 14:55, John M McIntosh <johnmci@smalltalkconsulting.com> wrote:

This was useful in doing our single threaded JavaScript to Multi-threaded Swift IOS platform code http://reactivex.io




....
John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk


Sent from ProtonMail Mobile


On Wed, Sep 4, 2019 at 15:32, N. Bouraqadi <bouraqadi@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?

Thanks for your help,
Noury
_______________________________________________
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org


_______________________________________________
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org