- Esug-list - lists.esug.org

Re: [Esug-list] Concurrency Best Practices + Tests

by Giovanni Corriga

Some random thoughts: 1) model your concurrency problem before you start with TDD, e.g. using TLA+. This will make clear what you need to implement using TDD. 2) once you have a satisfying result from 1, you can start designing your solution using TDD. Of the tests that you will need to write: - some will be pure behaviour tests which don’t to worry about concurrency - some will be coordination tests were you need to worry about concurrency. The coordination tests can be approached as simulation problems, where you can manage the choreography of the various concurrent processes. To do this: A) model your concurrent operation as transactions. Split the transaction execution into smaller steps, that can be tested separately. You can then set up a sequence of operations coming from multiple processes, interleaving ops from one process with those from the others. This will also make it easier to understand where to use coordination primitives. B) Explicitly manage the evaluation of the code in the two processes. You can do this with a creative use of method wrappers, Delay objects etc., or by forcing the code to run through a debugger, so that can manage the order of the message sends between the processes Please also note that TDD might not be enough and you might need to run other type of tests than TDD-style unit tests. Cheers, Giovanni Il giorno sab 7 set 2019 alle 03:25 Stéphane Ducasse < stephane.ducasse(a)inria.fr> ha scritto: > Hi guys > > I imagine that noury knows most of the remarks you sent it. > He is far from dull. > Now it would be nice to read his questions and reply to them and not just > tell him > “oh do not use concurrency” > > The questions are essentially how do we test? how does concurrent > programming fit in TDD. > > Stef > > > On 6 Sep 2019, at 02:32, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> > wrote: > > TL; DR: generally, developing a good sense of what to do ***before > writing a single line of code*** works really well. > > On 9/4/19 6:32 , N. Bouraqadi 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(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > . > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > -------------------------------------------- > Stéphane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley > <https://www.google.com/maps/search/40,+avenue+Halley?entry=gmail&source=g> > , > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Sept. 7, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Joachim Tuchel

I think the question was if there are any patterns or best practices to identify potential concurrency issues that could be used to build tools... maybe that’s why Complaints occurred...? > Am 07.09.2019 um 10:42 schrieb Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > >> On 9/6/19 23:24 , Stéphane Ducasse wrote: >> Now it would be nice to read his questions and reply to them and not >> just tell him “oh do not use concurrency” > > I did not say that at all --- yet you are complaining to me :). > >> The questions are essentially how do we test? how does concurrent >> programming fit in TDD. > > A sharper and more open minded question might be "what is the best way > to build reliable programs using concurrency flavor XYZ?". > > Andres. > >> >> Stef >> >>> On 6 Sep 2019, at 02:32, Andres Valloud >>> <avalloud(a)smalltalk.comcastbiz.net >>> <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: >>> >>> TL; DR: generally, developing a good sense of what to do ***before >>> writing a single line of code*** works really well. >>> >>>> On 9/4/19 6:32 , N. Bouraqadi 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(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >>>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >>>> . >>>> >>> >>> _______________________________________________ >>> Esug-list mailing list >>> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> -------------------------------------------- >> Stéphane Ducasse >> http://stephane.ducasse.free.fr >> http://www.synectique.eu / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Sept. 7, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Andres Valloud

On 9/6/19 23:24 , Stéphane Ducasse wrote: > Now it would be nice to read his questions and reply to them and not > just tell him “oh do not use concurrency” I did not say that at all --- yet you are complaining to me :). > The questions are essentially how do we test? how does concurrent > programming fit in TDD. A sharper and more open minded question might be "what is the best way to build reliable programs using concurrency flavor XYZ?". Andres. > > Stef > >> On 6 Sep 2019, at 02:32, Andres Valloud >> <avalloud(a)smalltalk.comcastbiz.net >> <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: >> >> TL; DR: generally, developing a good sense of what to do ***before >> writing a single line of code*** works really well. >> >> On 9/4/19 6:32 , N. Bouraqadi 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(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >>> . >>> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > -------------------------------------------- > Stéphane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Sept. 7, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Stéphane Ducasse

Hi guys I imagine that noury knows most of the remarks you sent it. He is far from dull. Now it would be nice to read his questions and reply to them and not just tell him “oh do not use concurrency” The questions are essentially how do we test? how does concurrent programming fit in TDD. Stef > On 6 Sep 2019, at 02:32, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > > TL; DR: generally, developing a good sense of what to do ***before > writing a single line of code*** works really well. > > On 9/4/19 6:32 , N. Bouraqadi 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(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> . >> > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 7, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Andres Valloud

TL; DR: generally, developing a good sense of what to do ***before writing a single line of code*** works really well. On 9/4/19 6:32 , N. Bouraqadi 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(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > . >

Sept. 6, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Andres Valloud

See Stefan Marr's talks at Smalltalks 2012. On 9/5/19 8:14 , Nowak, Helge wrote: > Adding to my previous speakers … > > > > At a (non-Smalltalk) conference I once watched a very comprehensive and > good presentation by a Professor who also worked for companies. So he > had both the theoretical and the practical background and he covered a > few different uses cases. The closing summary of his presentation was: > > - Concurrency is a must (in the light of the end of Moore’s Law) > > - Avoid concurrency as long as you can > > - If you really need concurrency then there is no > one-size-fits-all solution: each performance/scaling problem is > different and needs a different approach > > > > I am sorry I don’t remember the neither the name of the Professor nor > the name of the conference LYet if I do and find the presentation on the > web I will distribute the link here. > > > > Cheers > > Helge > > > > *Helge Nowak > *Cincom Smalltalk Technical Account Manager** > > http://internal.cincom.com/signature/logo.png > <http://www.cincomsmalltalk.com/> > Cincom Systems GmbH & Co. oHG > Humboldtstraße 3 > 60318 Frankfurt am Main > GERMANY > > > > office > mobile > > website > email > > > > +49 89 89 66 44 94 > +49 172 74 00 402 > > http://www.cincomsmalltalk.com > hnowak(a)cincom.com > > /A standpoint is an intellectual horizon of radius zero. -- Albert Einstein > > / > > Geschäftsführer/Managing Directors: Thomas M. Nies, Donald E. Vick > oHG mit Sitz/based in Frankfurt am Main (Amtsgericht Frankfurt am Main > HRA 50297) > Pers. haftender Gesellschafter/Partner liable to unlimited extent: > Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/Ts. > HRB 5069) > > > --- CONFIDENTIALITY STATEMENT --- > > This e-mail transmission contains information that is intended to be > privileged and confidential. It is intended only for the addressee named > above. If you receive this e-mail in error, please do not read, copy or > disseminate it in any manner. If you are not the intended recipient, any > disclosure, copying, distribution or use of the contents of this > information is prohibited, please reply to the message immediately by > informing the sender that the message was misdirected. After replying, > please erase it from your computer system. Your assistance in correcting > this error is appreciated. > > > > > > *From:*Esug-list <esug-list-bounces(a)lists.esug.org> *On Behalf Of > *Maarten Mostert > *Sent:* Thursday, 5 September 2019 10:57 > *To:* esug-list(a)lists.esug.org > *Subject:* Re: [Esug-list] Concurrency Best Practices + Tests > > > > Hello, > > > > Supposing you are working on a desktop app and you need to keep your > main image responsive and want to offload things to a worker image on a > separate processor you can hook it to the keyboard processor once finished. > > > > If you are basically making a clone of your image it is easy to make a > switch (dev/runtime) to do all the development and debugging in the same > image. > > > > This is at least my scenario. The main application works on a read-write > sqlite file. The worker makes a read only copy , slowly synchronises > everything with Postgres on compose.io <http://compose.io>, when > finished puts itself on the keyboard queue and when it his turn writes > the differences to the local sqlite work file and signals an UI update. > > > > The keyboard hook makes it possible for the worker to come back on the > main thread as a normal user interaction. > > > > Hope this helps, > > > > Maarten, > > > > > > Le 5 sept. 2019 à 10:27, Karsten Kusche <karsten(a)heeg.de > <mailto:karsten@heeg.de>> a écrit : > > > > Precisely my thinking! try to avoid concurrency as much as possible > and if you _really_ have to use it, try a queue approach. > > > > Georg Heeg eK > > Wallstraße 22 > > 06366 Köthen > > > > Tel.: 03496/214328 > > FAX: 03496/214712 > > Amtsgericht Dortmund HRA 12812 > > > > Am 5. September 2019 um 09:34:25, Tim Mackinnon (tim(a)testit.works > <mailto:tim@testit.works>) schrieb: > > > 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(a)smalltalkconsulting.com > <mailto:johnmci@smalltalkconsulting.com>> wrote: > > This was useful in doing our single threaded JavaScript to > Multi-threaded Swift IOS platform code http://reactivex.io > <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(a)gmail.com <mailto: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(a)lists.esug.org <mailto:Esug-list@lists.esug.org> > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Sept. 5, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Nowak, Helge

Adding to my previous speakers … At a (non-Smalltalk) conference I once watched a very comprehensive and good presentation by a Professor who also worked for companies. So he had both the theoretical and the practical background and he covered a few different uses cases. The closing summary of his presentation was: - Concurrency is a must (in the light of the end of Moore’s Law) - Avoid concurrency as long as you can - If you really need concurrency then there is no one-size-fits-all solution: each performance/scaling problem is different and needs a different approach I am sorry I don’t remember the neither the name of the Professor nor the name of the conference ☹ Yet if I do and find the presentation on the web I will distribute the link here. Cheers Helge Helge Nowak Cincom Smalltalk Technical Account Manager [http://internal.cincom.com/signature/logo.png]<http://www.cincomsmalltalk.com/> Cincom Systems GmbH & Co. oHG Humboldtstraße 3 60318 Frankfurt am Main GERMANY office mobile website email +49 89 89 66 44 94 +49 172 74 00 402 http://www.cincomsmalltalk.com hnowak(a)cincom.com A standpoint is an intellectual horizon of radius zero. -- Albert Einstein Geschäftsführer/Managing Directors: Thomas M. Nies, Donald E. Vick oHG mit Sitz/based in Frankfurt am Main (Amtsgericht Frankfurt am Main HRA 50297) Pers. haftender Gesellschafter/Partner liable to unlimited extent: Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/Ts. HRB 5069) --- CONFIDENTIALITY STATEMENT --- This e-mail transmission contains information that is intended to be privileged and confidential. It is intended only for the addressee named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited, please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. From: Esug-list <esug-list-bounces(a)lists.esug.org> On Behalf Of Maarten Mostert Sent: Thursday, 5 September 2019 10:57 To: esug-list(a)lists.esug.org Subject: Re: [Esug-list] Concurrency Best Practices + Tests Hello, Supposing you are working on a desktop app and you need to keep your main image responsive and want to offload things to a worker image on a separate processor you can hook it to the keyboard processor once finished. If you are basically making a clone of your image it is easy to make a switch (dev/runtime) to do all the development and debugging in the same image. This is at least my scenario. The main application works on a read-write sqlite file. The worker makes a read only copy , slowly synchronises everything with Postgres on compose.io<http://compose.io>, when finished puts itself on the keyboard queue and when it his turn writes the differences to the local sqlite work file and signals an UI update. The keyboard hook makes it possible for the worker to come back on the main thread as a normal user interaction. Hope this helps, Maarten, Le 5 sept. 2019 à 10:27, Karsten Kusche <karsten(a)heeg.de<mailto:karsten@heeg.de>> a écrit : Precisely my thinking! try to avoid concurrency as much as possible and if you _really_ have to use it, try a queue approach. Georg Heeg eK Wallstraße 22 06366 Köthen Tel.: 03496/214328 FAX: 03496/214712 Amtsgericht Dortmund HRA 12812 Am 5. September 2019 um 09:34:25, Tim Mackinnon (tim(a)testit.works<mailto:tim@testit.works>) schrieb: 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(a)smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> wrote: This was useful in doing our single threaded JavaScript to Multi-threaded Swift IOS platform code http://reactivex.io<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(a)gmail.com<mailto: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(a)lists.esug.org<mailto:Esug-list@lists.esug.org> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org<mailto:Esug-list@lists.esug.org> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org<mailto:Esug-list@lists.esug.org> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org<mailto:Esug-list@lists.esug.org> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Sept. 5, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Maarten Mostert

Hello, Supposing you are working on a desktop app and you need to keep your main image responsive and want to offload things to a worker image on a separate processor you can hook it to the keyboard processor once finished. If you are basically making a clone of your image it is easy to make a switch (dev/runtime) to do all the development and debugging in the same image. This is at least my scenario. The main application works on a read-write sqlite file. The worker makes a read only copy , slowly synchronises everything with Postgres on compose.io <http://compose.io/>, when finished puts itself on the keyboard queue and when it his turn writes the differences to the local sqlite work file and signals an UI update. The keyboard hook makes it possible for the worker to come back on the main thread as a normal user interaction. Hope this helps, Maarten, > Le 5 sept. 2019 à 10:27, Karsten Kusche <karsten(a)heeg.de> a écrit : > > Precisely my thinking! try to avoid concurrency as much as possible and if you _really_ have to use it, try a queue approach. > > Georg Heeg eK > Wallstraße 22 > 06366 Köthen > > Tel.: 03496/214328 > FAX: 03496/214712 > Amtsgericht Dortmund HRA 12812 > > Am 5. September 2019 um 09:34:25, Tim Mackinnon (tim(a)testit.works <mailto:tim@testit.works>) schrieb: > >> >> 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(a)smalltalkconsulting.com <mailto:johnmci@smalltalkconsulting.com>> wrote: >> >>> This was useful in doing our single threaded JavaScript to Multi-threaded Swift IOS platform code http://reactivex.io <http://reactivex.io/> >>> >>> >>> >>> >>> .... >>> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk <https://www.linkedin.com/in/smalltalk> >>> >>> >>> Sent from ProtonMail Mobile >>> >>> >>> On Wed, Sep 4, 2019 at 15:32, N. Bouraqadi <bouraqadi(a)gmail.com <mailto: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(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >>>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org <http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org> >>> >>> >>> _______________________________________________ >>> Esug-list mailing list >>> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org <http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org <http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org> > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org <mailto:Esug-list@lists.esug.org> > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org <http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org>

Sept. 5, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Karsten Kusche

Precisely my thinking! try to avoid concurrency as much as possible and if you _really_ have to use it, try a queue approach. Georg Heeg eK Wallstraße 22 06366 Köthen Tel.: 03496/214328 FAX: 03496/214712 Amtsgericht Dortmund HRA 12812 Am 5. September 2019 um 09:34:25, Tim Mackinnon (tim(a)testit.works<mailto:tim@testit.works>) schrieb: 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(a)smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> wrote: This was useful in doing our single threaded JavaScript to Multi-threaded Swift IOS platform code http://reactivex.io<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(a)gmail.com<mailto: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(a)lists.esug.org<mailto:Esug-list@lists.esug.org> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org<mailto:Esug-list@lists.esug.org> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Sept. 5, 2019

Re: [Esug-list] Concurrency Best Practices + Tests

by Tim Mackinnon

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(a)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(a)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(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Sept. 5, 2019