. These commands work by making deep copies of variables and values between the thread interpreters. But one big problem with threads in Tcl is that Itcl objects are not handled. They are just passed as strings to concurrent threads via tsv::set and tsv::get. The access command that every Itcl object has is not transferred, and so the object is not accessible in threads where it was not created. Deep copies, as with simple Tcl data types, are not very efficient and also not as easily possible here.To get Itcl objects transferred between threads, I worked on the guts of Itcl and created a patch. The changes I made are somewhat massive, so I wrapped up the sources, created binaries for Linux and Windows, as well as built it into my frequently renewed Tclkit. The results can be downloaded here: http://e-lehmann.de/?page_id=22.How it worksThere is nothing particular new to the usage of Itcl itself. It works like before, the only bit that changed is an additional flag during object creation: -threadshared or -ts. It needs to be given only if the object should be accessible in multiple threads. As an example, let's have a class A and create a thread shared object aobj - it would look like:
A -threadshared aobj ...or
A -ts aobj ...Where the three dots stand for additional options. The object creation mechanism recognizes the flag and creates & stores an access command for the new object in every present thread. The flag is also stored as object specific data and an access command is created for every new thread, if Itcl is loaded. When the object is deleted while there are access commands in different threads, just its thread specific access command is deleted. So it is not available anymore in a particular thread after deletion in that thread. When the object is deleted while it has an access command just in one thread, then the normal deletion process takes place (decrementing the refcount and eventually object deletion). The way it is implemented is particularly important: there is no interference with old Itcl code that runs in single-threaded environments. If the object is created without -threadshared, it behaves just like it does in one thread. This applies also if the object was created with -threadshared and there is only one thread. So nothing changes and old Itcl programs can be safely run with the new, threaded Itcl. I have verified this by running the test suite over and over. All 401 tests from the official Itcl pass (additionally the tests I added pass as well).The workflow for an Itcl developer who wants to take advantage of the threaded Itcl is relatively simple:
- create the class(es) in one thread and create the objects with the -ts option: ClassName -ts objname ...
- use tsv::set/tsv::get to set/get the object's name as shared variable if you don't know it in advance (e.g. if ::auto was used)
- modify the object in other threads, call methods on them, set values, whatever you want
- the objects are updated simultaneously in all threads.
[mikespry] - 2012-06-05 19:37:53anyone know where the source or binaries can by downloaded for this itcl patch? i'm looking for a way to share objects between tcl threads and this seemed like a good thing to try...if only the download link worked.
ABU 6 jun 2012I wonder if this mechanism could provide a simple method for sharing images between threads. Since loading and decoding a large image may takes several seconds, I ve tried to load an image in a worker thread, but then when the image data should be transferred to the main thread, it takes even more time ! If images could be shared between threads, it would be a great improvement. Do you think is it possible, or it s better to explore alternatives ?
