On Thu, Mar 06, 2008 at 06:48:04PM +0100, Guilhem Bichot wrote:
[skip]
> > Ok, I agree.
> >
> > About mutexes. Actually it is 8 byte => operations are atomic.
>
> Operations on 8 bytes are not atomic on all CPUs, there are
> exceptions. And there can be CPU caching effects.
sorry 8 bits (my_bool).
> > We drop the
> > flag before sending LSN to upper leven => nobody can use it for flushing
> > in the same moment and all previous flushes done (in other case
> > assignment do nothing). So we protects about only "flush everything
> > commands" for such commands IMHO it is ok if in next minisecoonds after
> > it appered something to flush. But "totally accidentally" we drop the
> > flag when have loghandler locked, and check it under serialization mutex
> > lock just to avoid potential problems.
>
> Ok, I am super-confused now.
> I realize that you read the variable under log_flush_lock and
> without translog_lock(), while you set it to 0 under translog_lock(),
> i.e. read and set using two different mutexes, I need to check the
> logic more (you talked about it above, but I have to think more).
> Without thinking, I'd protect the variable (reading and setting) just
> with translog_lock(), that would solve any potential issue.
> And there is also the problem that the log_flush_lock will be removed
> in the future, according to a comment in ma_loghandler.c.
Yes I forget about sync. I'll move check one line down after loghandler
lock.
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Oleksandr Byelkin <sanja@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Lugansk, Ukraine
<___/ www.mysql.com
