I just want to confirm.... If I have a tcl hashtable being accessed in two threads, and at least one of the threads can modify the value of an entry in the set (using the macro Tcl_SetHashValue), do I need to put a lock around every access of the hash table? (I think the answer would be yes, I would like to find out the answer is no.) To be specific, the nsvhr module stores a map of tuples (host, newlocation) in a Tcl hash table (entry, value). Tcl_HashSetValue(entry, value) is a macro which turns into something like: entry->clientData = value, where clientData is either *int or *void. This tells me that Tcl_HashSetValue is not atomic, and that there is an intermediate state in which the Tcl hash entry's value is neither the old value nor the new value. Currently, all is A-OK, as nsvhr only sets the values in this hash table during module initialization. I would like to extend nsvhr to be able to change the value of this hash table at runtime, so that a tcl proc can manipulate the behavior of nsvhr by adding/removing/changing the map at the same time that nsvhr itself is busy proxying requests for the rest of world. Do I need to lock all reads/writes to the hash table? Thanks, Jerry ===================================================== Jerry Asher [EMAIL PROTECTED] 1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980 Berkeley, CA 94709 Fax: (877) 311-8688
