An interesting problem :)

If I correctly understand what the BlitzLock is doing, then there are two possible problems with the code:

- pthread_cond_broadcast(&condition) should only be called, when scanner_count == 0 in scan_end() (or updater_count == 0).

For example:

pthread_mutex_lock(&mutex);
scanner_count–;
assert(scanner_count >= 0);
if (scanner_count == 0)
pthread_cond_broadcast(&condition);
pthread_mutex_unlock(&mutex);

- The other potential problem is so-called “live lock”:

This would happen, for example, if you had a constant flow of scanners. An updater would never get a chance because scanner_count would never go to zero. Possible solution is to have a limit to the number of scanners or updaters before you switch “modes”.

Best regards,

Paul

Graphs are always good. Writing that standalone is as far as I’ve gotten so it’s not integrated into the engine yet. When I get all the pieces together, I’ll definitely compare it against the native library and publish the results.

Thanks very much for the C++ tip!

I’m definitely not a C++ ninja but I thought adding code into a constructor/deconstructor wasn’t good practice since failure inside a constructor can be pretty yucky to take care of… Please correct me if I’m wrong but my understanding was that the constructor should only be used for allocation and basic initialization only, and bring out anything that involves assignments and further allocation into a different function like init().

This is something I’d love to know more about :)

Nice stuff. Would be nice to see if your homegrown implementation is more scalable than a standard rwlock. Can you post graphs of your findings in this regard?

Also, one little suggestion:

Change the BlitzLocK::init() into a constructor and BlitzLock::destroy() into the destructor. Since you are already paying the price of the constructor and destructor, you might as well move the init/destroy code into the constructor/destructor. This allows RAII principles to dominate as well, which means user of the BlitzLock class can’t make the mistake of forgetting to call init or destroy.

Cheers!

Jay

So tchdbput() is the interface that the application calls and the first argument of the function is the TCHDB object that contains the state information of the database file. If a different thread is doing something critical that needs total atomicity, it would have obtained a writer’s lock which would make a call to tchdbput() block until the writer’s lock is released.

I’m not sure if this is the answer you expected but TC has a rwlock called mmtx (no idea what it stands for) which protects the entry of TC’s API functions. I think peeking at tchdb.h (first struct in tchdb.h) would give you a good picture of what kind of mutexes are involved in TC’s hash database (it’s well commented).

>> MySQL has had a lot of trouble from taking locks before it needs to :(

Wish I knew more about it… too much things to study and too little time :)

Why is it taking *any* lock before doing this and the other work you mentioned? Again I don’t know the code, but in general locks should be taken as late as possible. MySQL has had a lot of trouble from taking locks before it needs to :-(