Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was reading Linux kernel Document and found in some places, they use task context and process context.

linux/Documentation$ grep -R "task context" .
./driver-model/driver.txt:147:The probe() entry is called in task context, with the     bus's rwsem locked
./DocBook/device-drivers.tmpl:429:  this writing all such functions are usable only from task context.
./gpio.txt:141:a task context.  However, for spinlock-safe GPIOs it's OK to use them
./gpio.txt:258:a task context.  However, for spinlock-safe GPIOs it's OK to request GPIOs
./PCI/pci-error-recovery.txt:134:shouldn't do any new IOs. Called in task context. This is sort of a

linux/Documentation$ grep -R "process context" .
./spinlocks.txt:110:manipulated from a "process context", ie no interrupts involved. 
./dma-buf-sharing.txt:286:   atomic dma_buf kmaps at the same time (in any given process context).
./DocBook/kernel-locking.tmpl:508:          If you are in a process context (any syscall) and want to
./DocBook/lsm.tmpl:152:have no process context (e.g. network input operations).

I understand the difference between process context and irq context, but AFAIK, process and task is not so much different in Linux (I guess I'm clearly wrong). Could anybody please enlighten me?

share|improve this question

migrated from Apr 9 '13 at 11:54

This question came from our site for professional and enthusiast programmers.

In the context of Linux kernel code they are synonymous.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .