Print indd

2
Related Work
The aim of our study is to improve synchronization mechanisms on MPSoC and
specifically the synchronization barrier. This subject has been largely studied
and many solutions, based either on software or hardware optimizations, have
been proposed. In this section we first present an overview of existing solutions
and then expose research directions that are still worth exploring.
Software-based solutions usually aim at speeding-up barriers by improving
barrier algorithms. In [
8
], Hoefler et al. present the principal algorithms designed
to implement synchronization barrier optimizing either the fastness or reducing
the potential contention issues resulting from simultaneous accesses to the same
resource (memory).
Nevertheless, some studies such as [
6
,
12
,
14
], highlight the fact that overheads
resulting from software processing are very expensive. Hence hardware proposals
have been formulated. Two trends can be identified:
(1) The addition of communication media dedicated to synchronization mech-
anisms like the “G-barrier” of Abell´
an et al. [
6
], which consists in imple-
menting a barrier with fast propagation link (g-line) and dedicated bar-
rier controllers. This proposal exposes very good results, however, the
“G-barrier”, like other solutions in the same trend [
9
,
11
], does not scale
very well since the addition of a processor requires extra barrier-dedicated

---

Optimization of the GNU OpenMP Synchronization Barrier in MPSoC
59
hardware (link and controllers). Another drawback of the “g-barrier” is that
the processors taking part in the barrier have to be known before the begin-
ning of the barrier. Moreover only a thread by processor can take part in
the barrier. All these restrictions make this proposal hard to use in real
operational systems.
(2) The second trend is the addition of a dedicated buffer to manage synchro-
nizations like the “synchronization buffer” of Monchiero et al. [
10
]. The
strength of this proposal is to unload the software from the synchronization
management, allowing it to perform other tasks during this time.
Proposed optimizations are numerous. All of them target the synchronization
primitive itself, trying to offer a new optimized mechanism. The main flaw of
these approaches is the poor studying of the mechanisms within their realistic
ecosystem environments before proposing a solution. Hence the majority of these
solutions have never been implemented in real operational systems. Our approach
differs on this point because we have chosen to carefully study an already wide
spread solution, in our case the OpenMP library, and then to improve it. We do
not directly target the low-level hardware mechanism nor the high-level software
algorithm but the middleware layer between the two. Thanks to our methodology
we are able to target real issues and to offer solutions usable seamlessly by
programmers.