Re: Threads

I noticed that the use of rate(...) introduces some conflicts to 
threads. Bruce Sherwood answers:
> I don't feel terribly competent concerning the threading aspects of
> VPython and have no ready explanation of what you've observed about
> sleep and rate. However, I have reason to expect that generally
> speaking, using the threading module should work okay, as you've
> found, because I believe that's all within the Python machinery. In
> contrast, the rendering thread that runs about 30 times per second
> shuts down Python completely while rendering is in progress.
Thank you.
This last point is not a problem. Python itself is a dinosaur, with its 
GIL (Global Interpreter Lock), and it is not very suitable to make 
something like an operating system, or a general multiprocessed 
simulation program within. But threads work well. This DOES NOT mean 
that they must work correctly with binary modules, such as cvisual, and 
it seems that we have such a case here.

The rendering doesn't show any pathologies - as far as my VERY 
INCOMPLETE tests show - but the function rate(...) seems buggy (from 
this perspective!). This is the simplified skeleton of my program, which 
moves the objects obj through the space

rr=RLock()
def move(args...):
    ...
    for i in seq():
         #          rr.acquire()
         # rate(1.0/slp)
         #          rr.release()
         obj.pos=newxyz()
         obj.trail.append(pos=obj.pos)
         time.sleep(slp)
...
t1=Thread(target=move, ...)
t2=Thread(target=move, ...) # with different params, geom and timing.
t1.start()
t2.start()
# =====================

This program works without any problems.
1. Comment time.sleep, uncomment rate(). Result: the thread t1 runs 
until completion, then the second particle starts moving. (Here the 
RLock is not used.) You can imagine my surprise...

2. Place rate() within a critical section, by uncommenting acquire() and 
release() of the reentrant lock, which can be released only by its 
owner. Ha! Try to guess what happens... (It is in principle possible, 
but not obvious.)

The behaviour is funny: the two particles move concurrently, but 
synchronized! Despite the differences in timing (the parameter slp), now 
in every thread exactly one step is executed before the relinquishing of 
control. Notice that I didn't put in the critical section the 
instructions which deal with the rendering!

Lesson to learn: if you want an *asynchronous parallelism*, even without 
race conditions or other conflicts, DON'T USE rate(), since - it seems 
(I looked up the file rate.cpp) - it uses one, global timer in a thread 
of its own, and that's it.

My proposal for the future versions of VPython, with (probably) rather 
feeble priority: either remove rate() altogether, and demand that the 
users use the timing procedures in the kernel of Python + the time 
module, etc.,

or revise thoroughly the threading aspects of cvisual.

==
Of course, it is quite possible that I am saying rubbish, it was just 
one hour of testing...

+++

A secondary comment on a slightly different subject. Bruce Sherwood says 
that the rendering thread works at a speed of about 30 frames/second. 
But VPython offers now the stereo vision, with the possibility to use 
shutter glasses.
I suspect that at this speed, it might be insufficiently comfortable for 
everybody... Perhaps it can be boosted and/or parameterized?...

Thank you very much, and my best regards.

Jerzy Karczmarczuk
Caen, France

PS. The complete version of the program if you want to check it, is here:
http://users.info.unicaen.fr/~karczma/TEACH/VPY/thr_test0.py

------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1

_______________________________________________
Visualpython-users mailing list
Visualpython-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/visualpython-users