[Firebird-devel] Problems with semaphores in CS

[John B. <bel...@cs...>]

Hi all,
	I have one question and one observation, both about the locking 
situation for the lock file/table in CS.  I'll start with some 
background.

The lock table is protected by a single mutex.  Only one process can be 
accessing the lock table at a time, period.  The lock table contains all 
the various locks for all the databases in the system.  If two processes 
are try to lock different entities in different databases at the same 
time there access to the lock table will be serialized, even though 
there changes won't conflict in every circumstance.

First, my observation.  I see a DOS attack with this setup.  Any program 
can grab the lock table mutex.  If they never give it back the DB blocks 
forever.  This attack is more sophisticated than the locksmith, but is 
still pretty easy to do. I still haven't come up with a good fix.

Second, my problem.  I'm testing the new mutex implementation, but am 
seeing the DOS first hand when a process holding the lock crashes.  The 
reason this isn't a problem with other mutex implementations is they 
have an automatic undo feature.  The code sets it up so when the program 
crashes to OS automatically releases the mutex hence no DOS.  My 
semaphore primitives don't have this.  Any suggestions on how to handle 
this.

I'm hoping there is a function in c that *always* gets called when the 
program is getting cleaned up including after crashes, but I haven't 
heard of one.  Anyone know of one?  I could add a call to a cleanup 
function in the assert code (that is where I'm bombing out), but that is 
not an all-encompassing solution.  I could also set up signal handlers 
to catch all deadly signals and do the clean up there, but I'm not sure 
that would work either.  Any thoughts?

Thanks.

-John