1
1
Граф коммитов

11 Коммитов

Автор SHA1 Сообщение Дата
Gilles Gouaillardet
4b91237464 opal/class/opal_lifo: use a standard syntax to initialize a local variable
opal_lifo.h is now included from C++, and g++ does not seem to accept C99 initializer.
2016-03-23 09:46:46 +09:00
Gilles Gouaillardet
013aec894b opal/class/opal_lifo: rename a local variable initially called new
this file is now indirectly included from C++, and new is a reserved C++ keyword
2016-03-18 22:15:44 +09:00
Nathan Hjelm
209a7a0721 opal/lifo: add load-linked store-conditional support
This commit adds implementations for opal_atomic_lifo_pop and
opal_atomic_lifo_push that make use of the load-linked and
store-conditional instruction. These instruction allow for a more
efficient implementation on supported platforms.

Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
2015-08-18 14:01:52 -06:00
Nathan Hjelm
6003a4dae1 opal/lifo: add missing opal_atomic_wmb and remove unnecessary opal_atomic_rmb
Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
2015-08-04 08:54:06 -06:00
Nathan Hjelm
298f238096 opal_lifo: add missing memory barrier to 64/32-bit atomic lifo
implementation

Need to ensure the head write is complete before updating the item's
next pointer.

References #371
2015-02-17 12:23:13 -07:00
Gilles Gouaillardet
5687ce8a07 Revert "opal/lifo: fix type declaration when cmpset_128 is available"
This reverts commit 1ba36175be.
2015-01-16 15:18:07 +09:00
Gilles Gouaillardet
1ba36175be opal/lifo: fix type declaration when cmpset_128 is available 2015-01-16 15:12:29 +09:00
Nathan Hjelm
7e5af9cecf opal_lifo: fix potential race condition when using 128-bit atomics
On x86_64 reading a 128-bit value requires multiple instructions.
Under some conditions if the counted pointer counter is read before
the item pointer the fifo can be left in an inconsistent state. This
commit forces the read of the counter to always be read first.

The fifo does not appear to suffer from the same race.
2014-12-10 12:51:44 -07:00
Nathan Hjelm
52ed5a9bf8 opal_lifo: fix one more potential issue with the new 128-bit lifo atomics
It is possible the compiler can reorder the read of the head item and
the head itself. This could lead to a situation where the item
returned was not really the head item.
2014-12-09 21:48:14 -07:00
Nathan Hjelm
a40fe8311f opal_lifo: add missing memory barriers in 128-bit atomic functions 2014-12-09 19:50:08 -07:00
Nathan Hjelm
20c6eb5237 Rename opal_atomic_lifo_t to opal_lifo_t and improve interface
- Rename opal_atomic_lifo_t to opal_lifo_t to reflect both atomic and
   non-atomic usage. Added new routines (opal_lifo_*_st) for non-atomic
   usage as well as routines conditioned off opal_using_threads(). The
   atomic versions are always thread safe and the non-atomic are always
   not thread safe.

 - Add a new atomic lifo implementation that makes use of 128-bit
   compare-and-swap. The new implementation should scale better with
   larger numbers of threads.

 - Add threading unit test for opal_lifo_t.
2014-12-04 15:30:02 -07:00