Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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
add comment

migrated from stackoverflow.com Apr 9 '13 at 11:54

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

1 Answer

In the context of Linux kernel code they are synonymous.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.