RE: Invitation to test cothread.catools release candidate

[<michael.abbott@diamond.ac.uk>]

From: matt.newville@gmail.com [mailto:matt.newville@gmail.com] On
> And, sorry for the questions, but I've always been a little confused
> by cothread.  Perhaps you could clarify some points for me?
> 
> Is there an advantage to using cothread over standard python threads?
> Is the idea that you have concurrent processes using "coroutines with
> yield" approach?    I'm afraid that I am missing an important
> use-case, especially wrt CA when using preemptive callbacks.      Is
> the principle issue that cothread tries to solve really with
> concurrent CA threads, or is is concurrency between CA and something
> else?     I'm sure this is just my lack of understanding,  but using
> CA with preemptive callbacks work fine for me with and without
> standard python threads, and I don't see an obvious need for more than
> that.
> 
> Could you give a simple example of where the advantages of the
> cothread approach really shine, perhaps something that cannot be done
> well without it?

This is a very interesting question.

There is of course quite a lot of history in the development of cothread, but I think it provides two main advantages:

1. Controlled concurrency.

This is a really big win, and is the main reason for the existence and success of this library.  As with all good things there are trade-offs and compensating problems, but the main advantage of coroutine based concurrency is that you never need to worry about locking.

I think it is well known that multithreaded programming is hazardous and fraught with difficult to reproduce race condition driven problems, and the programming errors frequently boil down to incorrect use of locks.  Using cothreads allows quite naive programmers to develop interactive and concurrent programmes without the hazards of worrying about concurrent access to shared data.  In particular camonitor updates will not arrive at inconvenient times.

With Python threads it seems to me that the biggest down side of cothread, that there is only one thread of execution, has much less impact, as Python only ever executes one thread at a time in the interpreter anyway!


2. Very light weight "threads"

The cothread library consists of a simple scheduling layer with associated event objects overlying a very basic coroutine switching engine.  Thousands of cothreads can be economically created, dispatched and destroyed in very short order, enabling a particularly straightforward style of coding.

Coding with callbacks requires a continuation style of programming mixed with threading based events when you need to resynchronise with the original caller.  This is definitely harder to write, particularly when exceptions and error handling need to be taken into account.


I've done a couple of experiments with rewriting catools without cothreads, and the two options are: (a) replacing cothreads with threads and leaving the code largely unchanged;  (b) rewriting to use callbacks up until the point of return to the user, at which point a threaded wait is clearly required to resynchronise.  I've done rewrite (a) and a preliminary rewrite for (b) for caget only with almost no error checking.  The results are interesting:

Option (a) is straightforward and requires little change to the existing catools.py code.  When fetching long lists of PVs (eg caget(pvs) for len(pvs) = 336 is a typical application) ordinary threads creak slightly: first it is necessary to configure quite a small default stack size, otherwise memory is exhausted and threads cannot be created (and everything crashes), and secondly cothread is about 50% faster.  Of course, this is unfair, so on to option (b).

In my opinion option (b) is certainly messier to write and it's quite a bit harder to do the error checking right ... however, caget on an array of 336 PVs is a trifle faster than with cothread, which is interesting. 


If there is interest I could complete and publish the "catools without cothreads" library?

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom