[lttng-dev] Quick questions about liburcu and RCU in general

[Mathieu Desnoyers]

Hi Richard,

* Richard Braun (rbraun at sceen.net) wrote:
> Hello,
> 
> I'm currently studying RCU/URCU, and I have a few questions that I wasn't
> sure where to ask.
> 
> 1/ Why use poll instead of sched_yield in e.g. force_mb_all_readers ?
> (I guess it's about portability and the effect is expected to be the same,
> but is there another reason ?)

poll() allow us to do a millisecond-level wait (timer-based).
sched_yield() is pretty much a scheduler hack that just says "be nice to
other scheduled processes here". Quoting sched_yield(2):

       If the calling thread is the only thread in the highest  priority list
       at that time, it will continue to run after a call to sched_yield().

This is a kind of behavior we don't want.

> 2/ What was the conclusion of the discussion regarding sys_membarrier ?
> (I couldn't find it in the main mail thread, and it looks quite interesting,
> even though I expect most carefully written applications not to exceed
> one thread per processor too much)

The conclusion so far was that:

- the implementation was fine,
- we had to show there were enough users of this new ABI to justify its
  inclusion and maintenance cost. Currently, it's pretty much just
  liburcu that uses it. As the number of liburcu users grows, this
  helps, but what would help even more would be to have other libraries
  and applications using sys_membarrier() (other people interested and
  weighting in).

> 
> 3/ Do you know if IBM allows the use of patented RCU techniques in GPLv3+
> code as well ? ("GPL" is mentioned in the Linux documentation, and
> apparently liburcu is covered by LGPLv2+ so I expect that to be the case,
> just looking for a confirmation)

AFAIK, LGPLv2+ code can migrate into GPLv3+, it's the other way around
that is not permitted. Therefore, I would expect it is allowed, but I
will let Paul answer to this one on behalf of IBM.

Thanks,

Mathieu


> 
> Thanks for your answers.
> 
> -- 
> Richard Braun

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com