lkml.org 
[lkml]   [2014]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ipc/sem.c: [RFC] memory barrier in sem_lock()
From
Date
On Tue, 2014-08-12 at 21:43 +0200, Manfred Spraul wrote:
> sem_lock right now contains an smp_mb().
> I think smp_rmb() would be sufficient - and performance of semop() with rmb()
> is up to 10% faster. It would be a pairing of rmb() with spin_unlock().
>
> The race we must protect against is:
>
> sem->lock is free
> sma->complex_count = 0
> sma->sem_perm.lock held by thread B
>
> thread A:
>
> A: spin_lock(&sem->lock)
>
> B: sma->complex_count++; (now 1)
> B: spin_unlock(&sma->sem_perm.lock);
>
> A: spin_is_locked(&sma->sem_perm.lock);
> A: XXXXX which memory barrier is necessary?
> A: if (sma->complex_count == 0)
>
> Thread A must read the increased complex_count value, i.e. the read must
> not be reordered with the read of sem_perm.lock done by spin_is_locked().
>
> But that's it, there are no writes that must be ordered.

Looks right. You might also replace the current (useless) comment with
the patch's changelog, describing why the barrier is there.

Thanks,
Davidlohr



\
 
 \ /
  Last update: 2014-08-13 05:01    [W:0.032 / U:1.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site