On 4/20/07, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi Pradeep... > I meant you can do some work which can sleep without any > worries.Apologies for not being clear. Ok got it now. In that case, then yes it is safe.. > But since work events can be scheduled and can be put to sleep as and > when kernel feels like putting them, why can't then a work event sleep > after intialising the delayed work in work_handler? I hope I get this part correctly. When you initialize the work even using INIT_DELAYED_WORK() or such, it means you just fill the related work event structure, but the event itself isn't scheduled yet. Once you call schedule_work(), then it is scheduled to run on certain CPU.
Ok, got it right.Thanks for it.
>Please note that > interrupts are very much enabled so our work can be put to sleep > waiting on the workqueue. > So this means there can more than one work events for the same wanting > to run same work handler on the workqueue.Which will run first we have > no way to know, untill we serialize them though using a semaphore i > guess. OK let me elaborate. Are you talking about one handler function being submitted to two different queue? If so, then yes.. it could be one of them running first followed by the other.
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. 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. CMIIW 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
