* Richard Braun ([email protected]) wrote: > On Tue, May 07, 2013 at 07:59:14AM -0400, Mathieu Desnoyers wrote: > > > 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. > > Right, I see. But then, poll enforces a minimum delay whatever happens > (which may be increased up to the scheduler time slice depending on the > kernel). I guess this isn't something we want either. > > On the other hand, AIUI, poll is called only after all signals were > already sent, and if a receiving thread didn't update its need_mb yet, > so I expect it's a rare worst case that doesn't require more care.
Indeed, that would be a rare worst case. Moreover, if we really care about this code path execution time, we might want to consider using the wait/wakeup scheme based on sys_futex used elsewhere in the urcu implementation. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
