home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / amiga / programm / 11469 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!torn!cunews!revcan!sidus!qube!atronx.OCUnix.On.Ca!rwm
  2. From: rwm@atronx.OCUnix.On.Ca (Russell McOrmond)
  3. Message-ID: <rwm.711692783@atronx.OCUnix.On.Ca>
  4. Date: 20 Jul 92 22:26:23 EST
  5. Newsgroups: amiga.prog,comp.sys.amiga.programmer
  6. Subject: Signal Semaphores
  7. Lines: 62
  8.  
  9.  
  10.   I'm wondering if anyone has done extensive work with SignalSemaphores under
  11. 2.04 (V37) that could let me know what I'm doing wrong with my use of them.
  12. I just put a 'Forbid()/Permit()' pair around all the things
  13. that 'should' have been protected by an ObtainSemaphore/ReleaseSemaphore
  14. pair in some multi-threaded code, and a large number of bugs just 'went away'.   
  15. Since I'd rather that ALL tasks didn't wait, and only those wanting access 
  16. to these structures, I'd rather get things working.
  17.  
  18.   The program in question runs many different processes, all of which share
  19. the same global variables.  When accessing any of the structures, I had put
  20. semaphore arbitration around the calls. Here's some 'example' code from what
  21. I'm doing:
  22.  
  23. typedef struct config_struct {
  24.   struct slave_struct mainSlave;
  25.   /* Slaves */
  26.   struct SignalSemaphore listLock;
  27.  
  28. ....
  29.  
  30.   if((myconfig=AllocMem(sizeof(config),MEMF_CLEAR))) {
  31.  
  32. ....
  33.  
  34.     InitSemaphore(&myconfig->listLock);
  35.  
  36. ....
  37.  
  38. int CountSlaves()
  39. {
  40.   slave *aslave;
  41.   int i;
  42.  
  43.   i=0;
  44.  
  45.   ObtainSemaphore(&myconfig->listLock);
  46.   Forbid();
  47.   FOREACH_LIST_UNSAFE(&myconfig->slaves,aslave)
  48.     if(aslave!=myconfig) i++;
  49.   END_LIST_UNSAFE;
  50.   Permit();
  51.   ReleaseSemaphore(&myconfig->listLock);
  52.   return(i);
  53. }
  54.  
  55.  
  56.  
  57.   All other calls are exactly the same as the Semaphore calles above.
  58. As mentioned, without the Forbid()/Permit() pair around the calls, everything
  59. crashes very quickly.  P.S. Yes, the InitSemaphore happens very soon after
  60. the memory is allocated, and long before any other semaphore operations are
  61. called.
  62.  
  63.   Thanks for any help.  The net has always been great for pointing out my
  64. stupid errors so I can quickly move on to getting some real work done! ;-)
  65.  
  66. ---
  67.   Opinions expressed in this message are my Own. I represent nobody else.
  68.   Russell McOrmond  rwm@Atronx.OCUnix.On.Ca Net Support:(613) 230-2282(V.32Bis)
  69.   FidoNet 1:163/109 Amiga-Fido 1:1/109  Current WELMAT 'keeper of sources'.
  70.  
  71.