Re: [PATCH 20/43] workqueue: reimplement work flushing using linkedworks

From: Oleg Nesterov
Date: Mon Mar 01 2010 - 13:53:54 EST

On 03/02, Tejun Heo wrote:
> On 03/01/2010 11:53 PM, Oleg Nesterov wrote:
> >
> > and in this case we put this barrier at the head of ->scheduled list.
> >
> > This means, this barrier will run after that work W, not before it?
> Yes, the barrier will run after the target work as it should.

You are right. it will run after target work == current_work and before
the next pending work W.


> > Hmm. And what if there are no pending works but ->current_work == target ?
> > Again, we add the barrier to ->scheduled, but in this case worker_thread()
> > can't even notice ->scheduled is not empty because it only checks ->worklist?
> A worker always checks ->scheduled after a work is finished.

Yes! I missed this, thanks.

> > insert_wq_barrier() also does:
> >
> > unsigned long *bits = work_data_bits(target);
> > ...
> > *bits |= WORK_STRUCT_LINKED;
> >
> > perhaps this needs atomic_long_set(), although I am not sure this really
> > matters.
> Yeah, well, work->data access is pretty messed up. At this point,
> there's no reason for atomic_long_t to begin with.

grep, grep, grep... arch/sparc/lib/atomic32.c uses spinlocks for
atomic_set() and ___set_bit(). Probably that is why atomic_long_set()
is really needed to avoid the race with test_and_set_bit(PENDING).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at