diff options
author | Andrea Parri <parri.andrea@gmail.com> | 2020-01-22 19:39:52 +0100 |
---|---|---|
committer | Tejun Heo <tj@kernel.org> | 2020-02-12 15:59:40 -0500 |
commit | dbb92f88648d6206bf22fcb764fb9fe2939d401a (patch) | |
tree | 6bf6e7a14ec2810a47c1fb841691feceacae3c85 /kernel/workqueue.c | |
parent | 0bf999f9c5e74c7ecf9dafb527146601e5c848b9 (diff) | |
download | linux-stable-dbb92f88648d6206bf22fcb764fb9fe2939d401a.tar.gz linux-stable-dbb92f88648d6206bf22fcb764fb9fe2939d401a.tar.bz2 linux-stable-dbb92f88648d6206bf22fcb764fb9fe2939d401a.zip |
workqueue: Document (some) memory-ordering properties of {queue,schedule}_work()
It's desirable to be able to rely on the following property: All stores
preceding (in program order) a call to a successful queue_work() will be
visible from the CPU which will execute the queued work by the time such
work executes, e.g.,
{ x is initially 0 }
CPU0 CPU1
WRITE_ONCE(x, 1); [ "work" is being executed ]
r0 = queue_work(wq, work); r1 = READ_ONCE(x);
Forbids: r0 == true && r1 == 0
The current implementation of queue_work() provides such memory-ordering
property:
- In __queue_work(), the ->lock spinlock is acquired.
- On the other side, in worker_thread(), this same ->lock is held
when dequeueing work.
So the locking ordering makes things work out.
Add this property to the DocBook headers of {queue,schedule}_work().
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'kernel/workqueue.c')
0 files changed, 0 insertions, 0 deletions