Hi Jim, Until now, we suspected that the way global locks are handled could be deadlock prone. You have just proved it.
I know that global locks are expensive on some systems, especially if we want to use them in a multiprocess (forked) environment. That's why we are forced to have such a small pool of global locks. On the other hand, in a multithreaded environment, locks which are valid for the whole process are not so expensive ; indeed, we can create a whole bunch without bringing down the system (think about Java where all object potentially have a monitor which is equivalent to a lock). I think this is a strong incentive to abandon the forked model and go for the multi-threaded model (or the mono-threaded, asynchronous one). For concurrency control, the forked model does not scale, apparently. Regards, Nicolas 2005/6/23, Jim Gallacher <[EMAIL PROTECTED]>: > I think I just spotted a potential deadlock in psp.py. > > def dbm_cache_store(srv, dbmfile, filename, mtime, val): > > dbm_type = dbm_cache_type(dbmfile) > _apache._global_lock(srv, "pspcache") > try: > dbm = dbm_type.open(dbmfile, 'c') > dbm[filename] = "%d %s" % (mtime, code2str(val)) > finally: > try: dbm.close() > except: pass > _apache._global_unlock(srv, "pspcache") > > "pspcache" will hash to one of 31 mutexes. Therefore there is a 1 in 31 > chance for a hash collision if a session is used in the same request, > which would result in a deadlock. > > I'm sure there are other possible deadlock scenarios where some > combination of sessions and pspcache could end up trying to hold the > same mutex. > > Most obvious solution is to use the global lock 0, which will serialize > all accesses to either pspcache.dbm (and the dbmsession dbm in the case > where DbmSession is being used). This will result in an obvious > performance hit when psp are used in conjunction with DbmSession, but > that's better than a deadlock. > > _apache._global_lock(srv, None, 0) > > The alternative would be to reserve a mutex for pspcache. > > If you agree that this is a possible deadlock let me know and I'll make > the simple fix. We could also take another look at the bsddb transaction > handling discussed last week in my Session benchmark post, and avoid > using the mutex altogether. > > Regards, > Jim >
