Re: [VANILLA-LIST:2626] Semaphore Testing

[Kurt Siegl <007@freemail.at>]

On Mon, 23 Aug 1999 you wrote:
>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

Thats already guaranteed by the daemon syncronisation, so not a big
deal here. Useless overhead.

>the move.  However the order in which the ntservs then update would
>probably be serialised as well.

Thats an additional syncronisation step. All (at least half) ntserv
processes are currently started exacly at the same time. If we have a problem
here we increased the probability of a race condition a lot by using DS. Since
the bug seems somehow to correlate with that time, maybe we should check 
ntserv processes interfering with each other.

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

I did my studies in parallel computation and all I can tell you here is that no
one uses it because its so terible inefficent.

>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.

That's the big danger with semaphores, you get deadlocks much more easy,
than it really helps.

Kurt

PS: I'm from 8. Sept to 5. Oct. in US (San Jose CA), with the last week free
for holiday if anyone likes to see me in person.

--
Kurt Siegl / Franzberg 4, A-4483 Hargelsberg, Austria
Email: 007@netrek.org       Tel (ISDN):   *(7225)7017
URL:   http://www.ooenet.at/user/siegl/kurt/