python threading and timing

[Oeyvind Brandtsegg]

hello

I'm writing a Python application for live music performance/improivsation,
using csound as the synthesis engine, and Python for compositional
algorithms, GUI and control.

I creating several threads:
one for GUI
one for csound,
one for a timed queue (timed automation events),
one for communication with a tcp based sensor interface.

My threads do not share data,
I use threads merely to enable several processes to run in paralell.
I think I do not need to use locks to control threads in this case,
but I'm not sure (?)

Also, I wonder what method I should be using to get a precise timing
in my automation thread (acting as a sequencer).

I've attached two simple examples of different ways I could implement threads.
The only task in these examples is to generate timed counters, but the
general procedure would be the same for more complex timed tasks.
One example uses time.sleep() to release a thread's interpreter lock,
and at the same time provide the time interval until the next
iteration.
The other example uses a thread event wait() call.

It seems that the example using wait() does not provide the same
precision as time.sleep() does (the counters does not sync, e.g. a
counter with a time interval of 0.1 does not count 10 times as fast as
a counter with a time interval of 1 second.

Any insights on how to do this the best way (thread safety and time
precision) would be greatly appreciated.

best
Oeyvind Brandtsegg

[Laurent Pointal]

Dennis Lee Bieber a écrit :

On Sun, 1 Oct 2006 22:28:10 +0200, "Oeyvind Brandtsegg"
<ob******@gmail.comdeclaimed the following in comp.lang.python:

>Also, I wonder what method I should be using to get a precise timing
in my automation thread (acting as a sequencer).

Use a real-time OS (which neither M$ Windows nor Linux/UNIX claim to
be).

All non-deterministic, multi-tasking, OS's (like Windows, Linux,
Solaris, AmigaOS) only guarantee that, for example, a sleep() call will
not return /before/ the time specified. There is no specification for
how much time /over/ the duration actually takes place.

And setting the task priority into the Windows "real-time" category
is not sufficient -- I had an application that had to put out data on
six pins of the parallel port (acting as three discrete RS-422 style
balanced signals) in time with a (1KHz, as I recall) clock signal coming
in on another pin of the parallel port. The data was still getting
glitches every ~256 clocks as the OS did something in the background.
(the application was written in VC++6, and even disabled the GUI during
the data output operation.

+++

realtime OSes != high level priority threads

And for a sound production using a sequencer, it looks like to need real
realtime.
And dont use Python threads for realtime multithreading, even on a
realtime OS (because of the GIL - Global Interpreter Lock).

May use Python for some -non realtime- parts, but I would not use any
scripting language (not specific to Python) for real-time work (prefer
C, ADA, maybe Java with ad-hoc extensions).

You may go to Python by writing a Python C extension module (doing
realtime work on its own - but never relying on python GIL in critical
times), communicating with normal python scripts (shared memory...
things which dont need the GIL if possible).

A+

Laurent.

[Cameron Laird]

In article <ef**********@upsn250.cri.u-psud.fr>,
Laurent Pointal <la*************@limsi.frwrote: