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)
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
Also notice that flushlock is unlocked first. Should it be the other
way around? I think so...
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.