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
