Return to race_condition CVS log

Up to [MW Coherent from dump] / coherent / f / usr / man / KERNEL

Annotation of coherent/f/usr/man/KERNEL/race_condition, revision 1.1.1.1

1.1       root        1: rraaccee ccoonnddiittiioonn -- Definition
                      2: 
                      3: 
                      4: The term  _r_a_c_e _c_o_n_d_i_t_i_o_n refers to  the condition that exists  when the the
                      5: outcome of  a sequence of  instructions cannot be  guaranteed.  This occurs
                      6: when program has two sections of  code that can run in any order and either
                      7: share a  variable or  change the  state of the  machine: the  code executed
                      8: first  wins  the  ``race''  and  so  controls  execution  of  the  program.
                      9: Obviously, it  is desirable to avoid  this situation; you can  do so if you
                     10: can force a certain ordering of the code sections.
                     11: 
                     12: Race conditions most often happen in operating system related environments.
                     13: If, as in  the case of a device driver,  your program has a main section of
                     14: code that manipulates a few variables  and it also has an interrupt handler
                     15: that does  the same, your  program must lock out  interrupts during certain
                     16: critical times to guarantee that the variables will not be compromised.
                     17: 
                     18: Consider, for example, the following pseudo-code:
                     19: 
                     20:     set interrupt priority to keep out the gremlins
                     21:     while (work is not yet completed)
                     22:         v_sleep( &some_variable_in_the_kernel_data_area )
                     23:     restore interrupt mask
                     24: 
                     25: If an interrupt  were to occur between the wwhhiillee  statement and the call to
                     26: vv_sslleeeepp(), the driver would never wake  up because the event it was waiting
                     27: for (sleeping  on) will  have already  occurred.  To avoid  this situation,
                     28: your  code must  this block  of  code with  calls to  the kernel  functions
                     29: sspphhii()/ssppll().  This will  ensure that interrupts  cannot occur  until after
                     30: vv_sslleeeepp() has  been called.  The system will  re-enable interrupts when the
                     31: driver calls  vv_sslleeeepp(), but  it is guaranteed  to have the  same interrupt
                     32: level (mask) when it awakens,  thus preserving the lockout of the interrupt
                     33: handler.
                     34: 
                     35: In most  cases, drivers lock out interrupts  when manipulating the internal
                     36: linked lists associated with tasks to be performed or buffers in use.  This
                     37: keeps the interrupt  handler from using stale data or,  worse yet, a linked
                     38: list that isn't correctly linked.
                     39: 
                     40: _S_e_e _A_l_s_o
                     41: ddeevviiccee ddrriivveerrss

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.