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

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