Missing Tcl command : semaphore
ulis
difficult.
Need of synchronization occurs when you animate a bit your game and
suddenly want to stop all. In my case this appends when the play times
out.
What was missing? Just a way to evaluate the current status
(waiting/playing/timed out). And the simpler and most versatile way is
to have a semaphore (http://wiki.tcl.tk/semaphores).
I think that implementing a semaphore command at the script level is
easy. It's just matter of incrementing/decrementing a value *WITHOUT*
interference at the script level.
A possible interface for a single threaded script with callbacks:
set sem [semaphore create ?name? ?initial-value?] ; # create a
semaphore
sem delete ; # delete a semaphore
set value [sem block] ; # lock the semaphore if its value is grater
than 0 else do nothing
if {$value == 0} { try later }
sem release ; # release the semaphore
Implementing a protected status with a semaphore is straitforward: the
semaphore is used as mutex (mutual exclusion lock) for the ::Status
variable.
ulis
David Gravereaux
single threaded Tcl might already have what you need. The command is
[vwait]
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]
ulis
> [vwait]
Thanks David.
In fact, I can't imagine a solution with vwait because my need is not
to have tasks waiting until being awaken but continuing until being
stopped.
Precisely: the running tasks are callback that recall themselves but
must stop at some events (time out or end of step). To do so a status
is maintained and tested by the callbacks. This status must be tested
before modified and so need an atomic test and set operation. A
semaphore is a conveniente way to simulate this operation.
ulis
Helmut Giese
Hm,
maybe there is some kind of misunderstanding:
While an event sink (a file event, a script scheduled via after, etc.)
is running, _no_ _other_ _event_ will get started - this will only
happen when thew first / current event handler yields.
Maybe you think in terms of an interrupt system, but this is not how
Tcl's events work.
Summary: You should be fine setting a (global) variable from within
one event handler to signal e.g. 'stop' to other handlers.
HTH
Helmut Giese
Chris Nelson
> ...
> single threaded Tcl might already have what you need. The command is
> [vwait]
An ugly solution; vwait's nest.
David Gravereaux
In non-threaded (and threaded too) Tcl, interps are ALWAYS in a single
state, therefore:
if {$someVar < 0} {
....
set someVar $otherValue
}
atomic operation are not needed, as the state of the interp won't be
modified between the test and set portions. This is not true of the
following:
if {$someVar < 0} {
....
update
....
set someVar $otherValue
}
If someVar is local to the scope, you can be sure it won't be different
coming back from purging the event loop, but if someVar is global or
namespaced, there is no guarantee that someVar *couldn't have* been
modified.
-- If you want an atomic test and set, do it from a single procedure. --
In Tcl, interpreter states are not concurrent. There is only one state an
interp has. There can be many interps running concurrent, but never
concurrent execution of a single interpreter state.
Bruce Hartweg
in a single thread program, if {$a == 0} {set a 1} *is* atomic.
you can have as many event handlers in the world, but only one
of them is runnin at a time. semeaphores/mutexes are somthing
you only need to worry about when dealing with shared resources
across 2 or more threads/processes. the only way to "interrupt"
an event handler is by explicitly doing something that will process
more events (update or vwait). so you can avoid it all together
or at the very least know exactly where something may have changed.
you don;t get arbitrary interpution or interleaving of processing.
Bruce
\
David Gravereaux
ulis
Effectively my implicit model was an interrupted system and was wrong
(it's difficult to think simple when you are complicated!).
With a callback (without update) never interrupted from the outerworld
there is no need for a synchronization mechanism.
Once again, thanks to all.
ulis