[Esug-list] Concurrency Best Practices + Tests

Andres Valloud avalloud at smalltalk.comcastbiz.net
Thu Sep 5 19:58:00 EDT 2019


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 at 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 at lists.esug.org> *On Behalf Of
> *Maarten Mostert
> *Sent:* Thursday, 5 September 2019 10:57
> *To:* esug-list at 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 at heeg.de
>     <mailto:karsten at 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 at testit.works
>     <mailto:tim at 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 at smalltalkconsulting.com
>         <mailto:johnmci at 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 at gmail.com <mailto: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?
>
>                 - 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 at lists.esug.org <mailto:Esug-list at lists.esug.org>
>                 http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>
>
>
>
>
>             _______________________________________________
>             Esug-list mailing list
>             Esug-list at lists.esug.org <mailto:Esug-list at lists.esug.org>
>             http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>
>         _______________________________________________
>         Esug-list mailing list
>         Esug-list at lists.esug.org <mailto:Esug-list at lists.esug.org>
>         http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>
>     _______________________________________________
>     Esug-list mailing list
>     Esug-list at lists.esug.org <mailto:Esug-list at lists.esug.org>
>     http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>
>
>
>
>
> _______________________________________________
> Esug-list mailing list
> Esug-list at lists.esug.org
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>



More information about the Esug-list mailing list