On Feb 23, 2007, at 8:31 AM, John Buckman wrote:
Should also get around to implementing "ns_mutex eval $mutex
$script"--acquire the mutex, evaluate the script, release the mutex.
Catch any Tcl errors and re-throw them. This guarantees that the
mutex
is unlocked, which avoids the trivial deadlock case:
mutex eval would be very handy, and "trylock" is fine by me, though
"tryandlock" would be handy, where the lock is obtained if it can be,
and if it can't be the function returns immediately with an error.
The C code for mutex lock appears to already support this (an E_BUSY
flat, if memory serves) but I didn' see a way to set a pthread to
return failure if a lock isn't possible.
To get around the error-causes-mutex-to-not-be-unlocked problem, I
created a "lock object" that automatically unlocks when the function
that created it goes out of scope.
You create a lock like this:
proc foo {
mooch_lock aLock
stuff...
}
(mutex unlocked automatically when function exits)
and this is the lock/unlock code:
proc mooch_lock {name} {
set mutex [nsv_get . $name]
uplevel 1 "set $name \"$mutex\";trace add variable bar unset
\"mooch_unlock $name\""
puts "locking $name / $mutex"
ns_mutex lock $mutex
}
proc mooch_unlock {name args} {
set mutex [nsv_get . $name]
puts "unlocking $name / $mutex"
ns_mutex unlock $mutex
return
}
that way, you don't need to use "eval" around code that is mutex
protected. The "trace" function handle mutex unlocking for you.
None-the-less, I still occasionally get a deadlock on my site, so
either this mechanism above isn't as robust as I think it should be,
or I have double-lock depending code somewhere on my web site.
-john
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
