On Sun, 25 Nov 2007 21:46:26 PST, kernel coder said: > hi, > > I have added some code to netif_receive_skb function.As linux kernel > is multhreaded , so there is no gaurantee than mine code is completely > executed without being disturbed by any other process .Timer interrupt > handler is an example of code which might interrupt execution of mine > code. The trick is to write your code so it doesn't *matter* if other code runs. For example - the timer interrupt almost certainly doesn't look at or modify any of *your* code's variables. So 98% of the kernel's code you don't even have to *care* if it runs (as long as you aren't doing something real-time or has similar response-time or throughput constraints). And if you are worried about that other 2%, where related code, for example the IRQ handler for a network interface, may have to look at and/or modify some of your variables, that's when you should be using appropriate locking - there's mutexes, semaphores, the whole RCU family, and more - none of which I'll attempt to explain, because I'm not all that good at that stuff. Basic rule of thumb - if you have something that will break if two things access it at the same time, put a lock around it, so they take turns.
Attachment:
pgpPcaW3fkRxm.pgp
Description: PGP signature
- References:
- profile code added to netif_receive_skb function
- From: "kernel coder" <[email protected]>
- profile code added to netif_receive_skb function
- Prev by Date: Re: Small System Paging Problem - OOM-killer goes nuts
- Next by Date: Re: [PATCH] file capabilities: don't prevent signaling setuid root programs.
- Previous by thread: profile code added to netif_receive_skb function
- Next by thread: 2.6.24-rc3-$SHA1: kernel BUG at fs/jbd/checkpoint.c:683!
- Index(es):
 |