ANN: Tcl Thread Extension 2.5
Zoran Vasiljevic
So, a small christmass present for the Tcl community
is here. After some months, the promised 2.5 version
is finaly ready. We have now a nice threadpool
implementation in both C and Tcl, some working examples
of Tcl web-servers and command line servers using Tcl
threads/threadpools, some new commands, fixes, improved
documentation, etc, etc.
Please fetch the new version from the Source Forge:
http://sourceforge.net/projects/tcl
Mary christmass and a very happy new year to you all!
Sincerely,
Zoran Vasiljevic
Summary of Changes since version 2.4:
-------------------------------------
o. Implementation of threadpools in C and Tcl.
Both of them share the same Tcl API and can be used
interchangeably. The C-level implementation is about
20-35% faster then the Tcl-only implementation. The
latter is done as an example of how such things could
be realized in Tcl alone.
The threadpool implementation is done so that it can
be effectively used in event-loop type of applications.
So, instead of blocking on a condition variable, the
implementation switches to the event-loop for all
blocking commands. This way, the application
may continue to work even when the caller is waiting
for a free worker thread or for a job to be processed.
o. configure options for builds as AOLserver loadable module.
One can now build the extension for AOLserver operation
out of the box by just specifying "--with-aolserver"
configure option.
o. AOLserver mutex and condition variables can also be
manipulated with the "thread::mutex" and "thread::cond"
commands. o. Example of a Tcl command-line server with
the ability to run each new session in a separate thread.
This way, each of the sessions can engage in a blocking
system call without blocking the main responder event loop.
Note: this example requires the Tcl8.4 core.
o. Example of a Tcl web-server using threadpool to distribute
load across many worker threads. This is a very powerful
concept implemented just in a couple of lines of Tcl code.
For comparison purposes, an event-loop version of the same
web-server is also supplied. Using apropriate test tools
like the "ab" (Apache bench) one can simulate parallel
concurrent load and measure server responsivness.
The threadpool based web server outperforms the event-loop
one by many orders of magnitude, especially for blocking
requests (a request to a Tcl script doing some blocking
system calls).
Note: this example requires the Tcl8.4 core.
o. New command "tsv::lock" which locks the shared variable
and executes the given Tcl script in one atomic operation.
Within the script, the same shared variable can be used
without internal locking. This is very convenient where
one needs to operate on several shared variable elements
in an atomic fashion.
o. New command "thread::eval" which serializes evaluation
of a Tcl script without the need of an extra mutex.
o. New commands "thread::detach" and "thread::attach" which
split the functionality of the "thread::transfer" in
two discrete steps. This is very convenient when doing
channel passing between the thread and the threadpool
and allows building of concurrent threadpool model with
one thread acting as responder and one or many threads
in the threadpool as workers.
o. The "thread::preserve" and "thread::release" commands
allow for preserving and releasing of the current thread.
The previously mandatory threadId parameter is now optional.
o. Documentation is now split across three files: one for the
thread::*, one for tpool::* and one for tsv::* set of
commands and revamped to include comments and remarks from
users. Many thanks to Markus Elfring for his suggestions.
[[Send Tcl/Tk announcements to tcl-an...@mitchell.org
Announcements archived at http://groups.yahoo.com/group/tcl_announce/
Send administrivia to tcl-announ...@mitchell.org
Tcl/Tk at http://tcl.tk/ ]]
Donald Arseneau
> So, instead of blocking on a condition variable, the
> implementation switches to the event-loop for all
> blocking commands. This way, the application
> may continue to work even when the caller is waiting
> for a free worker thread or for a job to be processed.
Excuse the naive question, but does this mean it fixes the
(ongoing, serious) problem of "recursive" event loops: that
tkwait and vwait will not re-activate until all subsequent
waits have been satisfied (they must complete in reverse order)?
(Oh please Please!)
Donald Arseneau as...@triumf.ca
Zoran Vasiljevic
>
> Excuse the naive question, but does this mean it fixes the
> (ongoing, serious) problem of "recursive" event loops: that
> tkwait and vwait will not re-activate until all subsequent
> waits have been satisfied (they must complete in reverse order)?
>
> (Oh please Please!)
Uups.. I'm not sure I'm aware about the problem you're
describing. Can you give me some more info?
Cheers
Zoran
Mike Hoegeman
Zoran ,
vwait is sometimes problematic in that when more than one tkwait is put into play
the "inner" tkwait(s) have to unwind before the "outer" tkwait(s)
actually unblock even if the outer level waits have already had the variable
set. That's expected behaviour as far as i am concerned, but people
like to imagine that wish is threading all it's various
event loop callbacks so that they can
employ tkwait with abandon for various synchronization purposes.
I on occasion like to imagine that too ;-)
Threads could help in this case because the you could
have the work currently being sychronized on via tkwait farmed out into threads
that a the caller thread could then sychronize on.
in this case you are just throwing
out the use of wait entirely which is fine, but your application still has to be
responsible for managing whatever synchronization needs to be done
if the application is sophisticated enough to know to use
worker threads for synchronizing on though it can many times also be made smart
enough to synchronize with something like the tk 'event' command..
with less effort expended..
-mike
>
> Cheers
> Zoran
--
Mike Hoegeman Habanero Technologies, LLC
http://habanerotech.net/personal-pages/mh/contact.html
Zoran Vasiljevic
> Threads could help in this case because the you could
> have the work currently being sychronized on via tkwait farmed out into threads
> that a the caller thread could then sychronize on.
> in this case you are just throwing
> out the use of wait entirely which is fine, but your application still has to be
> responsible for managing whatever synchronization needs to be done
I still have to admit that I did not undestand the issue :(
I have little Tk experiance 'cause I'm doing mostly server-side
stuff. I appologize for my ignorance.
Are there any short/simple examples of the problem you might
be able to give me? BTW, is Tk really thread-safe?
Can you load Tk into several threads without problems?
I assume you'd have to do that if you want to solve the
recursive vwait issue, but I'm not sure. Maybe somebody with
more Tk experience could step out and help?
Cheers
Zoran
Marty Backe
--
Marty Backe
-------------------------------
http://www.lucidway.org
- Who is John Galt?
Mads Linden
Mads
Jeffrey Hobbs
...
> be able to give me? BTW, is Tk really thread-safe?
> Can you load Tk into several threads without problems?
Yes, although there are still a few bugs lurking. Tk is thread-safe,
and it should work fine when running multiple Tk's in different
threads (I've done this a fair bit on Windows, and a little on *nix).
The areas where it gets fuzzy is apps that create and destroy interps
repeatedly over time. I know there is a bug with Tk UIDs being
overaggressive in thread shutdown. Thus, if all your Tk threads stop
at the same time you will be OK, but if not you may have issues.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions