home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 18041 < prev    next >
Encoding:
Text File  |  1993-01-02  |  2.3 KB  |  55 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!jato!jdickson
  3. From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
  4. Subject: Re: IPC and shared memory
  5. Message-ID: <1993Jan2.081756.21863@jato.jpl.nasa.gov>
  6. Organization: Jet Propulsion Laboratory
  7. References: <Jean-Guy_Speton.056u@tvbbs.wimsey.bc.ca> <paulk.317w@terapin.com>
  8. Date: Sat, 2 Jan 1993 08:17:56 GMT
  9. Lines: 44
  10.  
  11. In article <paulk.317w@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
  12. >> I am looking for information on inter-process communications (IPC)
  13. >> and shared memory functions.  Do the Amiga libraries have any
  14. >> functions along these lines?
  15. > 
  16. >Sure, there's PutMsg() eh.
  17. > 
  18. >> The reason I'm asking is I intend on writing a multi-line door, but
  19. >> have questions as to how the different processes of the door will
  20. >> communicate with one another.  I have a few ideas in mind, but they
  21. >> all seem as if they will become extremely slow and inefficient with
  22. >> more than a few lines.
  23. > 
  24. >Last time I messed around with a multiplayer game on a mainframe, the
  25. >way it was done, which worked pretty well, was to have an area of
  26. >memory that all the processes knew about, accessed through a locking
  27. >mechanism to protect crucial sections of code.  The way to do this
  28. >under AmigaDOS is with a named SignalSemaphore.  Tasks can arbitrate
  29. >access to the data by taking locks on the semaphore, and the process
  30. >of finding the semaphore by name allows the different tasks to all
  31. >get pointers to the same piece of memory, which the semaphore happens
  32. >to be the first item in.
  33.  
  34. Sure, a signal semaphore is the way to go, but for efficiency reasons I don't
  35. think named ones are a good idea. You see to guard against the slight chance
  36. the semaphore could go away whilest trying to find it via FindSemaphore - you
  37. are supposed to protect the operation with the Forbid/Permit pair. Not only 
  38. do you pull the plug on multitasking, but IMHO FindSemaphore is a waste of
  39. time if your usage of it is purely for the convenience of knowing it by name.
  40. I suggest simply making the signal semaphore globally known or just to the
  41. tasks/processes that wish to use it and forgo the FindSemaphore bit all
  42. together. Of course, this may not be an option. Just know that there is more
  43. than one.
  44.  
  45. Jeff
  46.  
  47.  
  48.  
  49.  
  50.  The way I
  51. do it is to make the signal semaphore known to every task/process that wishes
  52. to use it. This saves 
  53.  
  54.  
  55.