> On Fri, Feb 12, 2010 at 05:46:06PM -0500, Mathieu Desnoyers wrote: > > Here is an implementation of a new system call, sys_membarrier(), which > > executes a memory barrier on all threads of the current process. It can be used > > to distribute the cost of user-space memory barriers asymmetrically by > > transforming pairs of memory barriers into pairs consisting of sys_membarrier() > > and a compiler barrier. For synchronization primitives that distinguish between > > read-side and write-side (e.g. userspace RCU, rwlocks), the read-side can be > > accelerated significantly by moving the bulk of the memory barrier overhead to > > the write-side. > > > > The first user of this system call is the "liburcu" Userspace RCU implementation > > found at http://lttng.org/urcu. It aims at greatly simplifying and enhancing the > > current implementation, which uses a scheme similar to the sys_membarrier(), but > > based on signals sent to each reader thread. > > > > Editorial question: > > > > This synchronization only takes care of threads using the current process memory > > map. It should not be used to synchronize accesses performed on memory maps > > shared between different processes. Is that a limitation we can live with ? > > Acked-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> Yes. Personally, I think this patch's concept is clear and it can construct the base of userland lockless programming. If a userland programmer want to use lockless, hazard pointer is one of common technique and this syscall help it. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
