One point is that rate and sleep have different purposes.
rate is trying to make sure that each iteration of the loop takes a time slp. So to get the same effect from sleep, you would need to call time.sleep(slp-delta), where delta is the amount of time taken by the instructions in the rest of the loop.
On Nov 2, 2011, at 7:35 AM, Jerzy Karczmarczuk wrote:
> 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
> def move(args...):
> for i in seq():
> # rr.acquire()
> # rate(1.0/slp)
> # rr.release()
> t1=Thread(target=move, ...)
> t2=Thread(target=move, ...) # with different params, geom and timing.
> # =====================
> 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:
> RSA® Conference 2012
> Save $700 by Nov 18
> Register now!
> Visualpython-users mailing list