home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / misc / tornado / t2demo010a1 / Guidelines < prev    next >
Encoding:
Text File  |  1996-12-07  |  2.5 KB  |  47 lines
  1. (Note that some of this refers to features not implemented as yet in the
  2. support module)
  3.  
  4.  
  5. Guidelines for writing multithreading applications:
  6. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  7.  * Do NOT share handle-based resources between threads eg; one thread opens a
  8. handle and then passes that handle to another thread and then terminates. If
  9. you MUST do this, pass the handle to the other thread, and *enter* a wait
  10. cycle on that thread after tidying up. Should that thread ever terminate
  11. unnaturally, the thread that opened the handle will be exit that loop and
  12. then should close the handle if it's still open. Conversely, should the other
  13. thread successfully finish its work and no longer need the handle, it then
  14. should terminate and let the thread that created it close it.
  15.    In other words, ALWAYS open and close a handle with the same instance of
  16. thread. This is future-proofing as a future version of this support module
  17. may shut handles for a thread if it is ever forcibly terminated.
  18.  
  19.  * Do NOT linearly program. Mutexs and semaphores are there to be used - make
  20. the main message handler *dispatch* the message by starting up a thread -
  21. don't have the message handler handle the message itself where possible. This
  22. allows maximum responsiveness to be retained.
  23.  
  24.  * Make sure you 17, 18 & 19 poll code handler executes quickly as it is not
  25. preempted and thus both your code and the entire RISC-OS Wimp is held up
  26. until it finishes. Similarly to the point above, *dispatch* tasks into
  27. threads whenever possible and signal your handler. You should NOT attempt to
  28. call Wimp_Poll yourself during the handler.
  29.  
  30.  * Do NOT call Wimp_Poll yourself. Also make sure anything you do won't end
  31. up floating ie; if you send a wimp message, make sure your 17, 18 & 19
  32. handler can handle it correctly (eg; notify you).
  33.    An example of this is:
  34. <thread sends wimp message>
  35. <thread now suspends itself *with* timeout>
  36. <when wimp message returns into 17, 18 & 19 handler, handler resumes the
  37. thread>
  38. <all okay - unless wimp message is never replied to - in which case timeout
  39. occurs and then thread should take whatever action required>
  40.  
  41. This is how you should handle wimp messages that require replies. However,
  42. should the message exchange require no Wimp_Poll in between (eg; RAM
  43. transfers), then you should have your 17, 18 & 19 handler do the arbitration
  44. as it is the only part of your code that won't get preempted.
  45.    A nice effect of doing this is that suspending a thread leaves more time
  46. for other threads too so it's best all ways you look at it.
  47.