On Wed, Aug 22, 2012 at 1:46 PM, Kim, Milo <[email protected]> wrote: >> Hmmm, I think we still should use cancel_work() here based on your >> idea. Please find the patch from Tejun and add him to this loop >> [PATCH 4/6] workqueue: deprecate flush[_delayed]_work_sync() >> --- >> Before this patchset, >> >> flush_work() >> >> flush the last queued instance of the work item. If it got >> queued on multple CPUs, it only considers the last queued >> instance. The work item could still be executing on other >> CPUs and the flush might become noop if there are competing >> queueing operation on another CPU. >> >> flush_work_sync() >> >> flush_work() + wait for executing instances on all CPUs. The >> flush_work() part may still become noop if there's competing >> queueing operation. >> >> cancel_work() >> >> Dequeue the work item if it's pending. Doesn't care about >> whether it's executing or not. >> >> cancel_work_sync() >> >> cancel_work() + flush_work_sync(). >> >> >> After this patchset, >> >> flush_work() >> >> flush the work item. Any queueing happened previously is >> guaranteed to have finished execution on return. If no >> further queueing happened after flush started, the work item >> is guaranteed to be idle on return. >> >> cancel_work() >> >> Same as before. >> >> cancel_work_sync() >> >> cancel_work() followed by flush_work(). The same semantics as >> del_timer_sync(). >> --- >> >> cancel_work_sync() won't execute the work item at all just cancel >> them, but flush will execute them and return. >> > > Thanks a lot for the updates! > > Then, I think flush_work() should be used for executing remaining brightness > work > rather than cancel_work_sync(). >
Yeah, I agree here. I made a mistake about your original patch's description. -Bryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
