Messages in this thread | | | Date | Wed, 2 Jul 2008 20:33:31 +0400 | From | Oleg Nesterov <> | Subject | Re: [PATCH 2/3] workqueues: implement flush_work() |
| |
On 07/01, Jarek Poplawski wrote: > > On Tue, Jul 01, 2008 at 04:50:18PM +0400, Oleg Nesterov wrote: > ... > > Yes, cwq can be "stale", but this doesn't matter and we can't have > > the false positive here. > > > > cwq->current_work is always changed under cwq->lock, and we hold this > > lock. If we see "cwq->current_work == work" we can safely insert the > > barrier and wait. Even if this work was already re-queued on another > > CPU or another workqueue_struct. > > > > Note also that rmb() can't really help here. > > Right! The question is how "stale" this cwq could be when read without > any lock or barrier. Of course, there can't be the false positive, but > I wonder if we really do enough, to check if a work isn't current on > some other cwq, even without any immediate re-queuing.
Not sure I understand...
Of course, the work can be current on _all_ CPUs. So no, we don't do enough. Please look at the changelog, in particular the note about flush_work_sync().
But without re-queuing cwq can't be wrong? Once again, flush_work() flushes the result of the last visible queue_work(). If not requeued, the work is either current, or it is pending and list_empty() == F.
Oleg.
| |