Subj : Re: full-blown experiential smr-based reference counted pointer impl...
To   : comp.programming.threads
From : Joe Seigh
Date : Sat Apr 02 2005 05:17 am

On Fri, 1 Apr 2005 22:16:57 -0800, Chris Thomasson <_no_damn_spam_cristom@_no_damn_comcast.net_spam> wrote:

>>>> Yes.  Though with classical RCU the quiesent states aren't so near the
>>>> critical
>>>> regions and the membars are around the quiesent state itself, so they're
>>>> not
>>>> near the critical regions either
>
> Humm... I guess you might be able to emulate this beneficial behavior with
> user-space RCU. For instance... If user application logic happens to consume
> a batch of events from a server workqueue, executes the batch, then goes
> back to the queue to "wait" for more batches of objects to be pushed. The
> "wait" in this case could be considered a "natural user-application"
> quiescent point. The user would process multiple events ( the batch ) before
> the quiescent state shift happens, thus the depth of the batch affects the
> distance between the per-thread quiescent state transition points... Any
> thoughts?
>
>
>
>
>> With classical RCU, the quiescent states are voluntary context switches,
>> so
>> the RCU read lock and unlock macros are no-ops.  That's about as less
>> overhead as you can get.
>
> Yeah. I was considering collection pop function that blocks when empty to be
> a "voluntary" user-space context switch of sorts...
>
>

If you have a runtime environment that you have control over then you can
define the quiescent states in it.  You can't do that with a standalone
RCU.  If you define the quiescent states elsewhere, it has to be understood
that you're restricted from using functions that have quiescent states
in your RCU critical regions for that particular RCU implementation.


-- 
Joe Seigh

.