Olav and Vlad,
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)
break;
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
thread->shutdownInProgress?
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:
> Kevin,
>
> 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.
>
> Olav
>
>
