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:

> 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
My last commit on this topic implements it just like you suggest.

Thanks again for looking!


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