From: Kevin Lewis
Date: January 27 2009 3:33pm
Subject: Re: Bug 40633 pushbuild failure: Falcon assertion "lockState == 0"
 failed in SyncObject.cpp
List-Archive: http://lists.mysql.com/falcon/429
Message-Id: <497F2939.8070003@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 7BIT

 > 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)
>         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?

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:
>> 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
>>
>>
>