locking_rules.txt
上传用户:hongyu5696
上传日期:2018-01-22
资源大小:391k
文件大小:3k
源码类别:

PlugIns编程

开发平台:

Unix_Linux

  1. LOCKING RULES AND INVARIANTS:
  2. invariants:
  3. meaning of js_state are the following: 
  4. JS_STATE_UNDEFINED  means no player thread.
  5. JS_STATE_BUFFERING means thread is waiting on the condition variable.
  6. JS_STATE_INITIALIZING means thread was just started, but did not start
  7.          waiting on the condition variable yet.
  8. JS_STATE_TRANSITIONING means player thread is about to close the
  9.       connection and accessing control pipe is unsafe
  10.       (or control == 0).
  11. JS_STATE_PLAYING etc have the obvious meanings. 
  12. Locking Rules:
  13. (0) Rule: when player thread is dead (i.e. in shut after the 
  14.     pthread_join), no locking is needed (and no locking rules apply).. 
  15. (1) Rule: all read or write access to instance->js_state (in all threads) must 
  16.      be protected by control_mutex.
  17. (2) Rule: all read and write access to the playlist (i.e. td->list) must
  18.     be protected by playlist_mutex. 
  19. (3) Rule: No thread may block with control_mutex held.
  20. (4) Rule: If one needs to acquire both playlist_mutex and control_mutex,
  21.     playlist_mutex must be acquired first. Doing it in the other order
  22.     will deadlock.
  23. (5) Rule: all access to instance->control (from both threads) must be protected
  24.     by control_mutex. 
  25. (6) Exception to last rule: when js_state == JS_STATE_TRANSITIONING
  26.     player thread does not need locks for instance->control, 
  27.     but access by main thread is prohibuted.
  28. (7) Rule: In the player thread, any code which looks like
  29.     pthread_mutex_lock(&some_lock);
  30.     .... do stuff ....
  31.     pthread_mutex_unlock(&some_lock);
  32.   
  33.     where the ... do stuff ... includes a cancellation point, 
  34.     
  35.     must be protected by pthread_cleanup_push(pthread_mutex_unlock, some_lock)
  36.     and pthread_cleanup_pop(0)
  37.     
  38.     Recall that pthread_test_cancel(), pthread_cond_wait() and any
  39.     blocking system call/libc function is a cancellation point. 
  40. (8) Rule: instance->player is owned by the player thread. The only time
  41.     main thread can access it is when the player thread is already
  42.     dead (e.g. in shut after the pthread_join).
  43. (9) Corollary to above rules: 
  44.     All calls to sendCommand have to protected by control_mutex. Also
  45.     in player thread, calls to sendCommand have to be
  46.     protected by cleanup_push/cleanup_pop as well. 
  47. (10) Rule: Player thread may be started if there isn't one currently
  48.      (i.e. js_state == JS_STATE_UNDEFINED).  To start player thread, must do: 
  49.      pthread_lock(&control_mutex);
  50.      pthread_create(....)
  51.      js_state = JS_STATE_INITIALIZING;
  52.      pthread_unlock(&control_mutex);
  53. (11) Rule: to signal player thread, must use the signalPlayerThread()
  54.       function. 
  55. (12) Rule: to kill player thread, must do:
  56.  
  57.         pthread_cancel(&player_thread);
  58.         pthread_join(&player_thread);
  59.         js_state = JS_STATE_UNDEFINED;