This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for PR libgomp/37938, IA64 specific.


On Fri, 2008-11-07 at 11:33 -0800, H.J. Lu wrote:

> I am testing this patch. There is no need for memory barrier with acq semantics.
> 
> 
> H.J.

H.J.  I tried your patch and still had problems.  I think the change to
use acquire semantics is right, but it doesn't fix the problem.  In
looking at it I wonder about the release side.  In
libgomp/config/linux.h we have:

extern void gomp_mutex_lock_slow (gomp_mutex_t *mutex);
static inline void gomp_mutex_lock (gomp_mutex_t *mutex)
{
  if (!__sync_bool_compare_and_swap (mutex, 0, 1))
    gomp_mutex_lock_slow (mutex);
}

extern void gomp_mutex_unlock_slow (gomp_mutex_t *mutex);
static inline void gomp_mutex_unlock (gomp_mutex_t *mutex)
{
  int val = __sync_lock_test_and_set (mutex, 0);
  if (__builtin_expect (val > 1, 0))
    gomp_mutex_unlock_slow (mutex);
}

Now your change will make sure that the __sync_bool_compare_and_swap
builtin is done with aquire semantics (which seems right) but the unlock
part is done with __sync_lock_test_and_set and this does an xchg on IA64
which, in your earlier mail, you said also had acquire semantics.  Since
we are unlocking here don't we need release semantics?

Steve Ellcey
sje@cup.hp.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]