lkml.org 
[lkml]   [2014]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH] ipc/sem.c: [RFC] memory barrier in sem_lock()
Date
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.

---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index 454f6c6..a5c8a77 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -327,7 +327,7 @@ static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
/* Then check that the global lock is free */
if (!spin_is_locked(&sma->sem_perm.lock)) {
/* spin_is_locked() is not a memory barrier */
- smp_mb();
+ smp_rmb();

/* Now repeat the test of complex_count:
* It can't change anymore until we drop sem->lock.
--
1.9.3


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