Re: [AOLSERVER] mutex try lock?
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.
Re: [AOLSERVER] mutex try lock?
Dossy, The problem described is exactly what ns_cond solves. But what is the problem? Executing code withing a mutex lock which takes meaningful time. Instead with ns_cond, you use a mutex just so you can grab a condition variable, or at least try to grab it, and if not go to sleep and wait. Once you are woken up, you still have to try again to grab the condition var. But both mutex and sema will spin and use up cpu. John: there is a way to setup threadpools in AOLserver to limit the number of threads executing a page. But this still doesn't seem to be what your problem is here. The double submit problem has been around for a long time and I came up with a one page solution: on submit you make a signature of the variables using a hash of the unique inputs. Record the hash. Check if the hash is unique, abort if not. I stored the hash in a db, but it could easily go into an nsv if you are only worried about close-in-time uniqueness. This also allows users to back up and make small changes to input and resubmit. If the data is going into the database, usually the critical factor is that you don't get duplicate data, if the server is overloaded or not it seems like the mutex solution might not solve the uniqueness problem every time. tom jackson On Friday 23 February 2007 05:54, Dossy Shiobara wrote: On 2007.02.23, John Buckman [EMAIL PROTECTED] wrote: I'm trying to block the double submit problem on web pages, where a page submit takes too long (because something else is taking up the server), so the user hits cancel and resubmits. When the original taking-up-the-server code completes, now the two submissions occur at exactly the same moment, and the submission is processed twice. I currently use a database (check the database to make sure this operation hasn't previously run) call to prevent this, but if the two pages occur at the exact same moment, the database call isn't atomic enough to prevent the double-submit. What you really want is a condvar or semaphore, so yeah, I'd look at ns_cond or ns_sema. Before you start the work you'd sema down ... since only one thread can have the semaphore at a time, all the others will sleep. When that thread finishes, it must sema up and that'll wake up one other thread that has sema down'ed and is currently sleeping. Instead, to solve the double submit problem, I planned a more simple strategy: 1) try to grab a mutex, so I'm the only one doing this 2) if I can't grab a mutex, wait 1 second, and try again 3) after 5 seconds, give up on the mutex, and proceed anyway, since if there is a double-submit, chances are the two threads aren't running at the same moment any more. And, display an error, so that the programmer can investigate and see if there is a deadlock-causing bug in this code. Mmm, yeah, the whole desire a timeout urge is the problem, as I think ns_sema wait doesn't allow you to specify a timeout, either. So, the question becomes: is it better to add -timeout time to all the blocking subcommands, or to add ns_mutex trylock? In theory, -timeout 0 should perform the trylock equivalent. -- Dossy -- 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.
Re: [AOLSERVER] mutex try lock?
So, the question becomes: is it better to add -timeout time to all the blocking subcommands, or to add ns_mutex trylock? In theory, -timeout 0 should perform the trylock equivalent. I'd vote for -timeout on all lock requests, as that way I get both the see if lock is available functionality, as well as lock it if it's available, but give up after a few seconds if it isn't Generally, with any code I put into production, I try to put a sanity check in so that spectacular unexpected failures cause LOUD log warnings.,For normal semaphore locks, I might want to give up after 1 minute and display a warning in the log that there's likely a coding error in there (and I can even show a tcl stack trace to help find it). Otherwise, it's down to gdb and a core file to figure out what semaphores were blocking, and that's kind of ugly. I'm currently using nsv_incr to emulate this behavior, and it works well enough. -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.
Re: [AOLSERVER] mutex try lock?
That is how the ns_cache stuff works in 4.5. There is a maxwait flag that can be set when the cache is created. If one thread has the lock (updating the cache) the others will only wait a certain amount of time before timing out - good deadlock prevention. M On Feb 23, 2007, at 10:06 AM, John Buckman wrote: I'd vote for -timeout on all lock requests, as that way I get both the see if lock is available functionality, as well as lock it if it's available, but give up after a few seconds if it isn't -- 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.
[AOLSERVER] Easy Question
I hope. I am trying to build 4.5.0 on plain vanilla Fedora Core 6. First I had to make the utils/*.tcl executable, and add the shebang line for my tcl install. I assume that should not have happened and may give you a clue what I did wrong. nsthread_libinit.o: In function `_init': /usr/local/aolserver-4.5.0/include/nslibinit.c:42: multiple definition of `_init' /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crti.o:(.init+0x0): first defined here collect2: ld returned 1 exit status gmake[1]: *** [libnsthread.so] Error 1 gmake[1]: Leaving directory `/usr/local/aolserver-4.5.0/nsthread' make: *** [build] Error 1 Thanks for any advice... - Ian -- 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.
Re: [AOLSERVER] Easy Question
On 2007.02.23, Ian Harding [EMAIL PROTECTED] wrote: nsthread_libinit.o: In function `_init': /usr/local/aolserver-4.5.0/include/nslibinit.c:42: multiple definition of `_init' /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crti.o:(.init+0x0): first defined here collect2: ld returned 1 exit status gmake[1]: *** [libnsthread.so] Error 1 I thought I ran into this problem recently (but I can't remember where) but I do recall the fix involving adding -nostartfiles to CFLAGS for gcc. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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.
Re: [AOLSERVER] Easy Question
That rings a bell. Thanks! On 2/23/07, Dossy Shiobara [EMAIL PROTECTED] wrote: On 2007.02.23, Ian Harding [EMAIL PROTECTED] wrote: nsthread_libinit.o: In function `_init': /usr/local/aolserver-4.5.0/include/nslibinit.c:42: multiple definition of `_init' /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crti.o:(.init+0x0): first defined here collect2: ld returned 1 exit status gmake[1]: *** [libnsthread.so] Error 1 I thought I ran into this problem recently (but I can't remember where) but I do recall the fix involving adding -nostartfiles to CFLAGS for gcc. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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. -- 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.
Re: [AOLSERVER] Easy Question
El Fri, 23 Feb 2007 11:02:06 -0800 , Ian Harding [EMAIL PROTECTED] escribió: I hope. I am trying to build 4.5.0 on plain vanilla Fedora Core 6. First I had to make the utils/*.tcl executable, and add the shebang line for my tcl install. I assume that should not have happened and may give you a clue what I did wrong. A more elegant solution consists in editing the file includes/ns.mak and setting the TCLSH variable to the name of your interpreter (in my case, it's tclsh8.4). Regards, Juan José -- Juan José del Río Simple Option Tlf: 0034 616512340 Fax: 0034 952792455 [EMAIL PROTECTED] http://www.simpleoption.com -- 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. signature.asc Description: PGP signature
