On Thu, 21 Jul 2016 19:54:55 +0200 Manfred Spraul
wrote:
> Next update:
> - switch to smp_store_mb() instead of WRITE_ONCE();smp_mb();
> - introduce SEM_GLOBAL_LOCK instead of magic -1.
> - do not use READ_ONCE() for the unlocked&unordered test:
> READ_ONCE doesn't make sense for unlocked&unor
Next update:
- switch to smp_store_mb() instead of WRITE_ONCE();smp_mb();
- introduce SEM_GLOBAL_LOCK instead of magic -1.
- do not use READ_ONCE() for the unlocked&unordered test:
READ_ONCE doesn't make sense for unlocked&unordered code.
- document why smp_mb() is required after spin_lock().
Co
On 01/04/2016 02:02 PM, Davidlohr Bueso wrote:
On Sat, 02 Jan 2016, Manfred Spraul wrote:
Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a
race:
sem_lock has a fast path that allows parallel simple operations.
There are two reasons why a simple operation cannot run in paral
On Sat, 02 Jan 2016, Manfred Spraul wrote:
Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a race:
sem_lock has a fast path that allows parallel simple operations.
There are two reasons why a simple operation cannot run in parallel:
- a non-simple operations is ongoing (sma->s
Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a race:
sem_lock has a fast path that allows parallel simple operations.
There are two reasons why a simple operation cannot run in parallel:
- a non-simple operations is ongoing (sma->sem_perm.lock held)
- a complex operation is sl
5 matches
Mail list logo