#37 mutex recovery

[Prabakaran Thirumalai]

At present, if cleanup thread finds any dead process holding mutexes it shuts down the server.
This feature will enable recovery for unreleased mutexes by the dead process.

There should not be any reinitialization of the data, instead we should follow logging techniques to get back the consistent data.
CSQL uses following mutexes
a)ProcTable (for proc table allocation)
b)TransTable (for trans table allocation)
c)dbAlloc (for page allocations)
d)db (for all catalog table operations)
e)chunk (for allocation inside chunk)
f)bucket (for index bucket insertion)

Most of the time mutexes are taken so that no body updates the data structure concurrently. If proc exits holding mutexes at this state, then no need for any recover function.

If we can come up with recovery commands we can eliminate the reinitialization.
For example dbAlloc database mutex is taken when new page needs to be allocated from the database. This shall be divided into two logical negation operations.
a)FREE_PAGE with pageInfo* as argument
b)SET_CUR_PAGE with PageInfo* curpage as Ist argument and value to be set as IInd argument.

Using the above two commands we should be able to revert back to the consistent state before we acquired the mutex.
After we acquire the mutex, these commands will be put in the mutex object with respective values (kind of logical undo logs), then cleanup thread shall just execute these commands to recover the mutexes.
We need to check what all we do after acquiring mutexes and based on that come up with recovery commands.

dbmutex will be of great challenge as it does many many operations by acquiring the mutex. Also need to check whether we call increase the mutexes thereby increasing the concurrency. Currently at the beginning of createTable method we take dbmutex and release it toward the end. instead we can have multiple mutexes which will be acquired during the course, we will be able to increase the concurrency.