On 4/23/07, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi Pradeep... I am sorry. Lately, I can't reply fast...
No problem.:)
> 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.
may i ask why so?
> 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.
Yup ,thats very true.but my module is running on a uniprocessor system so i guess my previous arguments hold true on similar line. Thanks ~psr
regards, Mulyadi
-- play the game -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
