> Kevin Lewis wrote:
> It looks to me like cache:flushLock is used to synchronize between
> Cache::flush where syncWait is locked and Cache::ioThread where it is
> unlocked. Cache::ioThread should never be able to exit with syncWait
> still locked. But it looks like it can on line 960. if (!flushing)
> if (thread->shutdownInProgress)
> So maybe just as the last ioThread leaves and unlocks flushLock, a
> thread in cache::flush gets flushlock and locks syncWait one last time.
> We need a way for Cache::flush to determine, after it gets flushLock, if
> there are any ioThreads to signal. Should it check
Upon further reflection, this would be wrong since shutdownInProgress is
independent of flushlock. We need a variable controlled by
Cache::flushLock that says the ioThreads are done flushing, so don't
bother anymore. bool Cache::ioActive ???
> Also notice that flushlock is unlocked first. Should it be the other
> way around? I think so...
> storage\falcon\Cache.cpp(940): flushLock.unlock();
> storage\falcon\Cache.cpp(941): syncWait.unlock();
> Olav Sandstaa wrote:
>> Both Wlad and I have seen that it is the Cache::syncWait sync object
>> that is causing this assert. And I think both of us think that a quick
>> and safe solution is to test if this sync object is locked in the
>> Cache destructor and if so, then just unlock it. Do you agree that
>> that is an OK fix for pushing to the replication branch to make them
>> happy? To no longer make Falcon code a one of the stoppers for them
>> pushing to mysql-6.0 tree...... If you think this is OK then I will
>> make a patch - and after review push it to the replication branch.
>> Still, I think it will be good to understand why this situation
>> happened - and if this is a "bug" in the IO thread, then possibly fix
>> it so that the IO thread is able to do this unlocking of syncWait
>> properly. I have only briefly looked at the Cache::flush() and
>> iothread code so I do not fully understand it yet.