Kernel Korner - The New Work Queue Interface in the 2.6 Kernel
The first step in using work queues is creating a work queue structure. The work queue structure is represented by struct work_struct and defined in linux/workqueue.h. Thankfully, one of two different macros makes the job of creating a work queue structure easy. If you want to create your work queue structure statically (say, as a global variable), you can declare it directly with:
DECLARE_WORK(name, function, data)
This macro creates a struct work_struct and initializes it with the given work queue handler, function. Your work queue handler must match the following prototype:
void my_workqueue_handler(void *arg)
The arg parameter is a pointer passed to your work queue handler by the kernel each time it is invoked. It is specified by the data parameter in the DECLARE_WORKQUEUE() macro. By using a parameter, device drivers can use a single work queue handler for multiple work queues. The data parameter can be used to distinguish between work queues.
If you do not want to create your work queue structure directly but instead dynamically, you can do that too. If you have only indirect reference to the work queue structure, say, because you created it with kmalloc(), you can initialize it using:
INIT_WORK(p, function, data)
In this case, p is a pointer to a work_struct structure, function is the work queue handler and data is the lone argument the kernel passes to it on invocation.
Creating the work queue structure normally is done once—for example, in your driver's initialization routine. The kernel uses the work queue structure to keep track of the various work queues on the system. You need to keep track of the structure, because you will need it later.
Basically, your work queue handler can do whatever you want. It is your bottom half, after all. The only stipulation is that the handler's function fits the correct prototype. Because your work queue handler runs in process context, it can sleep if needed.
So you have a work queue data structure and a work queue handler—how do you schedule it to run? To queue a given work queue handler to run at the kernel's earliest possible convenience, invoke the following function, passing it your work queue structure:
int schedule_work(struct work_struct *work)
This function returns nonzero if the work was successfully queued; on error, it returns zero. The function can be called from either process or interrupt context.
Sometimes, you may not want the scheduled work to run immediately, but only after a specified period has elapsed. In those situations, use:
int schedule_delayed_work(struct work_struct *work, unsigned long delay)
In this case, the work queue handler associated with the given work queue structure will not run for at least delay jiffies. For example, if you have a work queue structure named my_work and you wish to delay its execution for five seconds, call:
Normally, you would schedule your work queue handler from your interrupt handler, but nothing stops you from scheduling it from anywhere you want. In normal practice, the interrupt handler and the bottom half work together as a team. They each perform a specific share of the duties involved in processing a device's interrupt. The interrupt handler, as the top half of the solution, usually prepares the remaining work for the bottom half and then schedules the bottom half to run. You conceivably can use work queues for jobs other than bottom-half processing, however.
When you queue work, it is executed when the worker thread next wakes up. Sometimes, you need to guarantee in your kernel code that your queued work has completed before continuing. This is especially important for modules, which need to ensure any pending bottom halves have executed before unloading. For these needs, the kernel provides a function to wait on all work pending for the worker thread:
Because this function waits on all pending work for the worker thread, it might take a relatively long time to complete. While waiting for the worker threads to finish executing all pending work, the call sleeps. Therefore, you must call this function only from process context. Do not call it unless you truly need to ensure that your scheduled work is executed and no longer pending.
This function does not flush any pending delayed work. If you scheduled the work with a delay, and the delay is not yet up, you need to cancel the delay before flushing the work queue:
int cancel_delayed_work(struct work_struct *work)
In addition, this function cancels the timer associated with the given work queue structure—other work queues are not affected. You can call cancel_delayed_work() only from process context because it may sleep. It returns nonzero if any outstanding work was canceled; otherwise, it returns zero.
- Readers' Choice Awards 2013
- Linux Kernel News - November 2013
- December 2013 Issue of Linux Journal: Readers' Choice
- Mars Needs Women
- RSS Feeds
- Raspberry Pi: the Perfect Home Server
- Sublime Text: One Editor to Rule Them All?
- Advanced Hard Drive Caching Techniques
- Web Administration Scripts
- IBM Will Minimize Impact of Future Disasters
- thanks for share, great
8 hours 43 min ago
- There are factors which are
13 hours 42 min ago
- Gnome 3 ?
14 hours 27 min ago
- Reply to comment | Linux Journal
18 hours 35 min ago
- "Redis RethinkDB 4.5%" on Best NoSQL Databases
1 day 4 hours ago
- on the ground
1 day 11 hours ago
- I was able to read the whole
1 day 12 hours ago
- since i have read the title i
1 day 15 hours ago
- Belanja Online Cari Voucher Diskon
1 day 15 hours ago
- The kernel doesn't really
2 days 4 hours ago