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     ! 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.