On 08/16/2011 12:58 AM, Lai Jiangshan wrote:
These series patches implelent a priority-boost urcu
based on pi-lock.
Some other locks(especial rcu_gp_lock) should be also
priority-aware, these patches did touch them and make
the patchset simpler.
While really cool, I found this patchset overly complex.
What we should introduce is abstractions over futexes. This is what I
did to experimentally port URCU to QEMU---my secret goal since commit
806f811 (use kernel style makefile output, 2010-03-01). :) Our use of
futexes is exceptionally similar to a Windows manual-reset event (yes,
Windows:
http://msdn.microsoft.com/en-us/library/system.threading.manualresetevent%28v=vs.80%29.aspx).
In QEMU I added the manual-reset event and use it in the
implementation of RCU.
By introducing an abstraction for this, we can make the code a lot
clearer and secondarily gain in portability. For QEMU portability was
actually my primary goal, but URCU might have different priorities. :)
PI futex support can also be implemented in the same framework.
By the way, it is my impression that MB (perhaps MEMBARRIER too?) is way
way more similar to QSBR than to SIGNAL:
MB rcu_read_unlock = QSBR rcu_thread_offline + nesting count
MB rcu_read_lock = QSBR rcu_thread_online + nesting count
Perhaps moving around code could make the code simpler? Following the
master/slave memory barrier functions is quite hard, and this is
complicated by the KICK_READER_LOOPS that (if I understand correctly)
makes little sense for non-SIGNAL models.
Paolo
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
