[MUD-Dev] Semaphores, Mutices, fd_sets

[clawrenc at cup.hp.com]

In <Pine.LNX.3.91.970426164344.1764M-100000 at uni-corn.demon.co.uk>, on
04/26/97 
   at 09:08 AM, Greg Munt <greg at uni-corn.demon.co.uk> said:

>I've seen the words 'Semaphore' and 'Mutex' thrown about in RGMA
>lately.  But I have no idea what they are. Would anyone be able to
>help me out?

They are more or less identical in practice, but the basics:

  A semaphore is an item which can atomically be queried for a 
  state, and if not present that state set.

The standard implementation here allows several basic manipulations on
a semaphore, with the most standard probably being: 

  Check the state of the semaphore.
  If the sempahore is set, block until it is unset and then try again.
  If it is not set, set it, and continue.

  This is commonly called "locking" the semaphore.  
  
  Processes that are blocked on the semaphore as said to be 
  "waiting" on it.

  (Of course with the above all done atomically)

And:

  Unset the semaphore I'm currently holding set.

  This is commonly called "unlocking" or "releasing".

And:

  Get the current set/unset state of the semaphore.

Inside this very general scope there are a lot of variations on
semaphores.  Unix has a particularly nasty variation as it explicitly
allows arrays of semaphores to be manipulated as above (lock, release
test) in one atomic operation, as well as having each individual
semaphore able to have any positive or negative int value (with all
the test/set etc APIs generalised for that).  <<Truth to tell, Unix
semaphores are even nastier than that>>

A mutex is just a variation on a semaphore.  Mutex stands for "mutual
exclusion".  Fairly simply its a semaphore type best that ensures that
only one user has access to a given resource at a time.  In Unix'es
case a mutex is just a standard semaphore with a bunch of wrappers
about it to make the API simpler/cleaner.

What OS do you want to know about semaphores and mutex'es for?

>Also, an fd_set holds FD_SETSIZE file descriptors. Is it true that a 
>theroretically infinite number of FDs can be opened by the server,
>and  that I can handle > FD_SETSIZE connections by having some kind
>of linked  list of fd_sets?

Almost always: No.  The exceptions are so rare and so limited as to be
ignorable (certain classes of list based OS'es etc).

Typically the base OS or OS kernel will have a built in limit of how
many files can be open in the system at a time.  Many OS'es will have
a similar (smaller) limit for processes, but its often the same. 
Per-process, or per-account permissions may reduce that number even
more.

Thus the XXX operating system can have up to, uhh, 9 files open at a
time.  However a single process can only have up to 8 files open at an
instant (one handle already being occupied with application opening
the file)  However, the great user Bubba, running the process may have
an account maximum of 3 files open at any one instant...

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...