Semaphore Testing

[Quozl <quozl@us.netrek.org>]

I'm just doing some testing using semaphore locking of the shared
memory access.  I've placed a lock around the daemon's move() and
in a few critical ntserv functions like intrupt() and doRead().

This serialises _most_ accesses to the shared memory, such that the
ntserv processes will defer their action until the daemon has finished
the move.  However the order in which the ntservs then update would
probably be serialised as well.

Test results: on a 486/100 server with 16 clients on isolated ethernet,
I saw no difficulty sustaining five updates per second per client.
CPU load was below 0.10, and "time tcpdump -c 10000 -w /dev/null port 2592"
showed expected numbers.

Does anyone here have much experience with SYS V semaphores?
I've implemented this test using semop(), but would appreciate some
technical review.

Although the lock in the daemon was simple, the lock in ntserv either
has to be in all sorts of odd places, or "inverted" around the wait
for player input ... e.g.

unlock();
wait-for-input();
lock();

But that could lead to locks held if the ntserv stalls on a TCP write.
Very bad.  Already it is a possibility the way I've coded it.

-- 
James Cameron                                      (quozl@us.netrek.org)

Linux, Firewalls, OpenVMS, Software Engineering, CGI, HTTP, X, C, FORTH,
COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.

"Specialisation is for insects." -- Robert Heinlein.