Vanilla List Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VANILLA-LIST:2603] base etempbug...



On Fri, 20 Aug 1999 you wrote:
>> Well I tried, and for the life of me, I can't hit the race condition
>> deliberately.  
>
>But if there's no semaphore locking, then the possibility is non-zero, 
>correct?  Therefore, if we want to make robust code, semaphore locking
>should be added out of general principle.  Granted, it may slow things
>down a little, but it's not like people are running servers on Sun3's or
>386's...
>
>Either way, adding it would be a win, I think.

Netrek never had any real semaphore memory protection and has been running
with that already for a long time. I had a server (melmac) which was running
on a 20 Proc shared memory machine for years without any problems.

The good thing is that critical writing is done by the daemon only, so there
is hardly any conflicting access. And now with daemon syncronisation 
the processes are synced even better so that there shouldn't be a conflict
due to missing semaphores at all.

I asume the problem is more an algorithmic one due to some missing flag
clearing.

Theory is one thing, but praxis is a completely other topic.

Kurt (007)

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