Difference between revisions of "Linearizability"
m (not sure what the underlined bits mean) |
m |
||
| Line 1: | Line 1: | ||
| − | On Wikipedia it is [[Wikipedia:Linearizability|stated | + | On Wikipedia it is [[Wikipedia:Linearizability|stated]] that: |
"The easiest way to achieve linearizability is by forcing groups of primitive operations to run sequentially using critical sections and mutexes. Strictly independent operations can then be carefully permitted to overlap their critical sections, provided this does not violate linearizability. Such an approach must balance the cost of large numbers of mutexes against the benefits of increased parallelism. | "The easiest way to achieve linearizability is by forcing groups of primitive operations to run sequentially using critical sections and mutexes. Strictly independent operations can then be carefully permitted to overlap their critical sections, provided this does not violate linearizability. Such an approach must balance the cost of large numbers of mutexes against the benefits of increased parallelism. | ||
Another approach, favoured by researchers but usually ignored by real programmers as too complex, is to design a linearizable object using the native atomic primitives provided by the hardware. This has the potential to maximise available parallelism and minimise synchronisation costs. Unfortunately, it also generally requires correctness proofs that are publishable results, as almost every conference on concurrent programming since the start of the 90s has demonstrated." | Another approach, favoured by researchers but usually ignored by real programmers as too complex, is to design a linearizable object using the native atomic primitives provided by the hardware. This has the potential to maximise available parallelism and minimise synchronisation costs. Unfortunately, it also generally requires correctness proofs that are publishable results, as almost every conference on concurrent programming since the start of the 90s has demonstrated." | ||
| − | |||
| − | + | This is the method is that the project is using - the nodal-core provides the atomic primitives which integrate with the hardware level as closely as possible. | |
| − | |||
| − | |||
| − | + | Starvation and lockups remember are reduced by the ability to distribute the use of resource over the network - ie optimisation of the parts is handled by the whole. | |
| + | |||
| + | The OS part of the project (peerix) will use the local nodal space as its filing system, and use a nodal interface, but it still runs over the Linux kernel and therefore we have no control over the wait/lock performance of that level. | ||
Revision as of 00:48, 31 July 2006
On Wikipedia it is stated that:
"The easiest way to achieve linearizability is by forcing groups of primitive operations to run sequentially using critical sections and mutexes. Strictly independent operations can then be carefully permitted to overlap their critical sections, provided this does not violate linearizability. Such an approach must balance the cost of large numbers of mutexes against the benefits of increased parallelism.
Another approach, favoured by researchers but usually ignored by real programmers as too complex, is to design a linearizable object using the native atomic primitives provided by the hardware. This has the potential to maximise available parallelism and minimise synchronisation costs. Unfortunately, it also generally requires correctness proofs that are publishable results, as almost every conference on concurrent programming since the start of the 90s has demonstrated."
This is the method is that the project is using - the nodal-core provides the atomic primitives which integrate with the hardware level as closely as possible.
Starvation and lockups remember are reduced by the ability to distribute the use of resource over the network - ie optimisation of the parts is handled by the whole.
The OS part of the project (peerix) will use the local nodal space as its filing system, and use a nodal interface, but it still runs over the Linux kernel and therefore we have no control over the wait/lock performance of that level.
