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