A search on the Wiki for "mutex*" and "semaphore*" turned up nothing
interesting (other than a link to a missing page at neosoft). So, does
anyone have a Tcl extention that does semaphores on 'Windows that might
be extended to do them on UNIX? Any thoughts on Tcl syntax and
semantics for semaphores?
Chris
--
Christopher Nelson, Senior Software Engineer Pinebush Technologies,
Inc.
Author: Tcl/Tk Programmer's Reference
http://www.purl.org/net/TclTkProgRef
>I've long felt that Tcl needed a platform-indepedent semaphore or mutex
>command which would allow scripts to coordinate with each other and with
>programs in compiled languages such as C. I'm now rather in need of
>such a feature and am considering writing it but don't want to invent my
>own wheel if I can steal or spruce up someone elses.
>
>A search on the Wiki for "mutex*" and "semaphore*" turned up nothing
>interesting (other than a link to a missing page at neosoft). So, does
>anyone have a Tcl extention that does semaphores on 'Windows that might
>be extended to do them on UNIX? Any thoughts on Tcl syntax and
>semantics for semaphores?
>
> Chris
Hi Chris,
It's already done. Grab Tcl's thread extension.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tcl/thread/generic/threadSpCmd.c?rev=1.2&content-type=text/vnd.viewcvs-markup
https://sourceforge.net/cvs/?group_id=10894
http://tcl.activestate.com/ftp/thread/
--
David Gravereaux <davy...@pobox.com>
Thanks but looking at
http://tcl.activestate.com/ftp/thread/thread20.html and
http://tcl.activestate.com/ftp/thread/thread21.html I don't see anything
about semaphores.
I'm not trying to coordinate threads in a single process; I'm trying to
get Tcl access to OS-level semaphores. I want to be able to do things
like:
if {[catch {mutex::create "aResourceOrMutexName"} mutex]} {
puts "Someone got here first"
exit
}
...do some processing...
$mutex release
or
# Yes, I _know_ this loop is awful. I just want to show mutex stuff
while { ! [mutex::acquire "aName"]} } {
after 1000
}
# Got it...
...do our thing
mutex::release "aName"
>coordinate with each other and with
>programs in compiled languages such as C.
Chris,
That part is a bit sticky. I could make GetObjFromHandle() a public function,
so you could share/grab the condition variable with a C program, but then you'd
need to use Tcl_ConditionNotify/Wait(). Let me know, I'm the thread extension
maintainer now.
Currently, the thread extension doesn't provide any public interface except for
the Tcl commands. I don't see any reason why it couldn't provide any useful
functions given a good reason.
--
David Gravereaux <davy...@pobox.com>
>Thanks but looking at
>http://tcl.activestate.com/ftp/thread/thread20.html and
>http://tcl.activestate.com/ftp/thread/thread21.html I don't see anything
>about semaphores.
It's in 2.1, but not documented as such.
--
David Gravereaux <davy...@pobox.com>
>I'm not trying to coordinate threads in a single process; I'm trying to
>get Tcl access to OS-level semaphores. I want to be able to do things
>like:
>
> if {[catch {mutex::create "aResourceOrMutexName"} mutex]} {
> puts "Someone got here first"
> exit
> }
> ...do some processing...
> $mutex release
Ok, I gotcha. Named Mutexes. Not something that the thread APIs in Tcl do.
Tcl mutexes are done with critical sections on windows. Looks like you'll need
to write the routines as a different extension.
--
David Gravereaux <davy...@pobox.com>
Wrapping the existing Tcl_Mutex calls in a few custom library commands will cover the
scripting end. The tricky part to me is to deal with passing the mutex handle that
you dynamically create in the script call to the custom command mutex::create (not
the "aResourceOrMutexName" part, but the actual handle) to your using thread, so it
knows what to deal with. If you have a priori known resources, you can define the
mutexs statically and store them in a hash and pass the name into the script. This
may make life easier.
Since the Tcl_Mutex calls use the OS dependent thread API, the Tcl_Mutex calls
themselves are OS independent. However, your thread will also have to call the
Tcl_Mutex API.
To grab the mutex in the script I believe you would have:
mutex::acquire "aName"
Since the block will take place in C inside the Tcl_MutexLock call.
Tom Wilkason
>Since the Tcl_Mutex calls use the OS dependent thread API, the Tcl_Mutex calls
>themselves are OS independent. However, your thread will also have to call the
>Tcl_Mutex API.
>
>To grab the mutex in the script I believe you would have:
>mutex::acquire "aName"
>
>Since the block will take place in C inside the Tcl_MutexLock call.
Tom,
I don't think that could work on windows. A Tcl_Mutex on windows is really a
wrapper to critical sections.
http://msdn.microsoft.com/library/psdk/winbase/synchro_5xwz.htm
http://msdn.microsoft.com/library/psdk/winbase/synchro_2dke.htm
Chris wants a wrapper to named mutexes for sharing across different processes.
http://msdn.microsoft.com/library/psdk/winbase/synchro_3bsj.htm
http://msdn.microsoft.com/library/psdk/winbase/synchro_1a2g.htm
--
David Gravereaux <davy...@pobox.com>
Didn't realize he wanted it across different processes, I was thinking threads in the
same process. If that is the case, as you said, the Tcl API won't work.
|
Tom Wilkason
Did you check out the following two extensions for examples of how
people have done this in the past?
What: System V ipc
Where: <URL: ftp://ftp.neosoft.com/languages/tcl/sorted/packages-7.6/net/svipc-2.2.0/svipc-2.2.0.tar.gz>
<URL: http://www.zx1.com/tcl/ftparchive/sorted/net/svipc-2.2.0/>
Description: Tcl interface to System V IPC facilities. Supports
Unix Tcl 7.5 dynamic loading.
Updated: 10/1998
Contact: <URL: mailto:j...@zircon.seattle.wa.us> (Joe Kelsey)
What: Tcl IPC interface
Where: <URL: ftp://ftp.neosoft.com/languages/tcl/alcatel/extensions/tclipc1-0.tar.gz>
Description: Implements Tk's send command without requiring Tk or X11.
Updated:
Contact: <URL: mailto:gil...@noao.edu> (Kim Gillies)
--
--
"See, he's not just anyone ... he's my son." Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
Tom,
Yeah, I thought he just wanted to use a Tcl_Mutex with Tcl_MutexLock/Unlock at
first, too. Chris is looking for a new behavior of a named mutex. It looks
like the thread extension may get some OS specific stuff after all. Semaphores
will be fun to add, I have to admit. All this stuff at the script-level is
kinda scary.
--
David Gravereaux <davy...@pobox.com>