From: Date: July 4 2008 10:46am
Subject: Re: mutex contention for the query cache
List-Archive: http://lists.mysql.com/internals/35803
Message-Id: <486DE365.2010103@mysql.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

note:
i haven't really thought about this in the context of the query cache...
i've been more thinking about the table-definition-cache

Jonas Oreland wrote:
>>> /me tries to promote RCU as silver bullet
>>> if mysqld can define a well-defined grace period, then /me thinks this
>>> can be used in several places
>> I dno't know, how do you do RCU in the userspace ?
> 
> I think the only "tricky" thing is to define a synchronization point,
> other than that it's "only" a RW-lock, wo/ mutexes on read-side, and lazy object removal
> 
> ***
> define synchronization points so that you are not allowed to keep rcu-pointer across them.
> - i think a natural place would be per statement or such,
>   but I dont know enough of mysqld-internals find a good place for sure
> 
>   (the linux equivalent of these are context-switches,
>    where you not allowed to keep a RCU-pointer across context-switches)
> 
> So the way I think of it is that each statement (or maybe network-request (or something else))
> - registers itself in current RCU-context, this will be one atomic operation (i.e XADD or similar)
>   (and keep track of pointer to RCU-context)
> - unregisters itself when statement is finished (using one atomic operation (i.e XADD or similar)
> 
> The register/unregister will be a hot spot, but the thread can in between read wo/ mutexes.
> 
> anyone wanting to make a RCU-update (should be rare, or construct is not appropriate right)
> 1) lock mutex
> will create a new RCU-context, atomically replace global-RCU-context-pointer
> wait for old-RCU context to become "clear", perform needed removals
> 2) unlock mutex
> 
> ---
> 
> Above is very sketchy...terminology is vague...but I think/hope you get the idea..
> And it's basically assumes that it's cheaper to perform a register/unregister-pair than to lock
> individual mutexes "while working"
> 
> I think this assumption can be made to be true, i.e different threads, can register on different cache-lines
> so that contention should be quite rare...
> 
> hmmm...also I think would be quite easy to impl. with the thread-pool that exists in 6.0
> but I'm not really sure, as dont know what it really does (only what I guess that it does)
> 
> ---
> 
> What do you think ?
> 
> /Jonas
>