Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
>> map<Lock*, map<site_t,Lock*>, LockPtrLessOperator> TH> That's just overcomplex. Just use: TH> map<Lock*,int> TH> Since the main lock list holds the correct mapping & that array is only TH> used in the one fuction. Current implementation can use multiple locks for the same object, so in the outer map there will be one entry for the each path, and all locks for the same path will be in the nested map. The main optimization will be in the request_lock() function. The search will be done in two steps. The first step will find the subset of the locks for the specified path. The second step will check each of those locks. Probably the nested container should not be a map, and a vector or a linked list will be enough. TH> Also there's no point in uppercasing as the lockserver is case sensitive TH> on all platforms. Just replace the loop with a strcmp which is an TH> intrinsic function and compiles to very efficient code. LockParse.cpp: 469: LockClientMap[client].fncmp=case_insensitive?lc_strcasecmp:lc_strcmp; 811: if((locklen==pathlen && !LockClientMap[client].fncmp(path,i->second.path.c_str()))) Am I missed something ? TH> For large numbers of concurrent users the lockserver isn't the criticial TH> part - the memory, IO and cpu overhead of all the cvs.exe processes is TH> far greater. lockserver is called at least twice (lock & unlock) for each file during update, so it also uses CPU. -- Best regards, alexey-panchenko mailto:alexey-panchenko at hotmail.ru