Hi Pradeep...
I am sorry. Lately, I can't reply fast...
No, i mean same handler function, differnt work events and same
workqueue.After i submit it using schedule_delayed_work(), the handler
function can be put to sleep, so this means there are now two handler
functions in the waitqueue.One which i just submitted and other one
which was just put to sleep and has exhausted a part of its time
slice.
OK, same handler but submitted twice? So there is a possibility it is
not the handler itself that re-queue itself later, but another code path
(which runs concurrently)? Then yes, I think you need somekind of
serialization.
However, even though I don't know your real design is, I still suggest
to find a way to avoid serialization as much as possible.
Which one now will schedule?If i want serialisation in the sense that,
the handler which got the CPU first should always finish first i guess
i ll need a semaphore.
To give you a picture, even if two handler submitted to different CPU
with the same expiration time, there is a chance one would run first
then followed by the other. This is derived from the fact that Linux
kernel doesn't guarantee real time timer execution, so workqueue handler
could be deferred several miliseconds later than the actual deadline.
regards,
Mulyadi
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
