* Chris Friesen (cfriesen@xxxxxxxxxx) wrote: > On 02/12/2010 04:46 PM, Mathieu Desnoyers wrote: > > > 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 ? > > It makes sense for an initial version. It would be unfortunate if this > were a permanent limitation, since using separate processes with > explicit shared memory is a useful way to mitigate memory trampler issues. > > If we were going to allow that, it might make sense to add an address > range such that only those processes which have mapped that range would > execute the barrier. Come to think of it, it might be possible to use > this somehow to avoid having to execute the barrier on *all* threads > within a process. The extensible system call mandatory and optional flags will allow this kind of improvement later on if this appears to be needed. It will also allow user-space to detect if later kernels support these new features or not. But meanwhile I think it's good to start with this implementation that covers 99.99% of use-cases I can currently think of (ok, well, maybe I'm just unimaginative) ;) Thanks, Mathieu > > Chris -- 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
