"Also ODP implementations are expected to handle a lot of the mutual exclusion and synchronization in dedicated hardware, obviating the need for a lot of performance optimized software solutions."
This is the key architectural distinction between ODP and other software-centric solutions. The ODP APIs are attempting to capture *functional abstractions *that we expect (over time) to be implemented directly in hardware. This is why we don't want APIs that presume an implementation model or that expose implementation details. A good API allows an application to state concisely *what it wants* and gives the implementation flexibility to determine how to provide the requested functionality in an optimal manner. On Tue, Dec 2, 2014 at 9:20 AM, Ola Liljedahl <[email protected]> wrote: > On 1 December 2014 at 23:47, Maxim Uvarov <[email protected]> wrote: > > Hello, > > > > Paul E. McKenney (kernel rcu maintainer) just published new articles > about > > memory models and atomic things. I guess it might be interesting for > > everybody: > Yes good stuff. Thanks for digging this up. > > > > > N4321: Towards Implementation and Use of memory order consume > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4321.pdf > Looks very interesting. I will save it for this evening in the sofa. > > > > > Linux-Kernel Memory Model > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4322.html > Note that much of the memory barriers semantics etc are defined using > C11/C++11 memory models (which extend the Release Consistency model > from where acquire and release definitions come). Why cross the river > for water? > > Linux seems to invent the optimal solution for each and every use case > in the kernel, leading to a lot of locking and atomics primitives. To > quote the article: "The Linux kernel has an embarrassingly large > number of locking primitives". I think this makes the Linux model > difficult to use (the pieces of it that you use would have to be a > consistent subset used in the proper way) and to understand (and > understanding is important for correct usage). Also ODP > implementations are expected to handle a lot of the mutual exclusion > and synchronization in dedicated hardware, obviating the need for a > lot of performance optimized software solutions. > > > > > Out-of-Thin-Air Execution is Vacuous > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4323.html > > > > Use Cases for Thread-Local Storage > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4324.html > > > > > > BR, > > Maxim. > > > > _______________________________________________ > > lng-odp mailing list > > [email protected] > > http://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
