Nathan
- If you look at the code it does lock before attempting to any manipulation to
that array.
#####################################
ns_share counter_A
ns_share counter_B
ns_share -init
{ set counter_mutex [ns_mutex create] }
counter_mutex
proc X {i} {
ns_share counter_A
ns_share counter_B
ns_share
counter_mutex
ns_mutex lock
$counter_mutex
incr counter_A($i) 1
incr
counter_B($i) 1
ns_mutex unlock $counter_mutex
}
proc_doc
Y {} {
ns_share
counter_A
ns_share counter_B
ns_share counter_mutex
ns_mutex lock
$counter_mutex
foreach i_index [array names counter_A] {
set
temp_counter_A($i_index) $counter_A($i_index)
set temp_counter_B($i_index)
$counter_B($i_index)
unset counter_A($i_index)
unset
counter_B($i_index)
}
ns_mutex unlock
$counter_mutex
## writing $temp_counter_A and $temp_counter_B arrays to
database
}
#####################################
-----Original Message-----In a message dated 1/27/2003 2:22:09 PM Eastern Standard Time, [EMAIL PROTECTED] writes:
From: Nathan Folkman [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 27, 2003 2:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [AOLSERVER] ns_mutex is likely causing our AOL web server to hung
Regarding the error handling in this code, as you see, the only thing is between the lock/unlock block is just incrementing the arrays, and also the database action takes places after unlocking. Since the existence of the arrays also is being tested and takes place before attempting to use ns_mutex, I'm assuming that no error could cause the ns_mutex unlock to be skipped because of an exception, plus nothing shows up in the error log either.
careful - you might have a race condition. consider this scenerio:
THREAD 1:
- check for existance of array(key)
- lock
- do something with array(key)
- unlock
THREAD 2:
- unset array(key)
thread 2 could unset your array after you've checked for its existance, and before you did something with it. to fix the scenerio above you'd need to lock around all access to your array and move the check for existance inside the lock as well:
THREAD 1:
- lock
- check for existance of array(key)
- do something with array(key)
- unlock
THREAD 2:
- lock
- unset array(key)
- unlock
better still is to catch and handle errors around code which acquires a mutex lock. this allows you to properly unlock and prevents dead lock situations where you've acquired a lock, an error occurs, and you never release the lock.
one other note about the nsv_incr command. in versions prior to 4.0 you need to first initialize the the nsv array and variable you are incrementing:
nsv_set myArray counter 0
nsv_incr myArray counter
in 4.0 the nsv_incr will create and initialize the array and variable if it doesn't already exist:
nsv_incr myArray counter
- nathan
