List:Commits« Previous MessageNext Message »
From:Vladislav Vaintroub Date:September 11 2010 8:45pm
Subject:RE: bzr commit into mysql-trunk branch (vvaintroub:3194) Bug#56585
View as plain text  

> -----Original Message-----
> From: Dmitri.Lenev@stripped [mailto:Dmitri.Lenev@stripped] On Behalf Of Dmitry Lenev
> Sent: Thursday, September 09, 2010 9:36 PM
> To: Vladislav Vaintroub
> Cc: commits@stripped
> Subject: Re: bzr commit into mysql-trunk branch (vvaintroub:3194) Bug#56585
> 
> Hello Vlad!
>
Hello Dmitri,

> I think I have found yet another issue with rw_pr_lock
> implementation:

<skip>
> Sounds like a deadlock? Or do I miss something?

Nope, you're right, thanks for spotting. There is a possibility for deadlock.

> It seems to me that problem can be solved if we ensure that decrement
> of reader_count and setting of allow_writer event will happen atomically
> (within scope of reader_cs critical section).

> And, yes, this probably means that unlock will get more expensive in
> case of multiply readers case, but as we have discussed this is not
> the most common case in MDL.
> 
> BTW if both increment and decrement of reader_count will be protected
> by the same critical section they no longer have to be done as
> Interlocked operations.
> 
> What do you think?

I think it makes sense. I just measured what does Enter/Leave critical section on unlock()
costs  for sysbench readonly scenarios,
and the difference is not measurable. And  unless there is a big number of readers locking
and unlocking at the very same time(which
you say does not happen), enter/leave critical section will the same overhead as an atomic
operation. 
 
My last commit on this topic implements it just like you suggest.

Thanks again for looking!

Vlad

Thread
bzr commit into mysql-trunk branch (vvaintroub:3194) Bug#56585Vladislav Vaintroub7 Sep
Re: bzr commit into mysql-trunk branch (vvaintroub:3194) Bug#56585Dmitry Lenev9 Sep
  • RE: bzr commit into mysql-trunk branch (vvaintroub:3194) Bug#56585Vladislav Vaintroub11 Sep