Path: utzoo!attcan!uunet!munnari!otc!metro!ditsyda!evans
From: evans@ditsyda.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: mini_send, should it lock()?
Summary: It already does ... mostly
Keywords: mini_send
Message-ID: <1043@ditsyda.oz>
Date: 11 Jan 89 13:32:13 GMT
References: <352@lzaz.ATT.COM>
Organization: CSIRO DIT Sydney, Australia
Lines: 29

In article <352@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes:

>The following is a fragment of code from kernel/proc.c
>in MINIX/ST. It is probably the same as PC 1.3.
>It seems to me that this code needs to use lock() and restore()
>[most of mini_send()]

It *is* locked since both hardware interrupts and the software interrupt
for a system call disable interrupts (at least in PC Minix 1.3).

However, there seem to be some oversights in the implementation.

1) The system task calls functions in proc.c directly in a few places, and
there is no software interrupt to do the lock.

2) The clock task calls rs_flush() which calls interrupt(), and there is
no hardware interrupt to do the lock.

Point 2) is fixed in the "Yet another TTY" I posted earlier this month.
Point 1) is fixed in the proc.c I use. System calls set a guard variable
'switching' to allow the task switching code to run with interrupts enabled
(to reduce latency). 'Switching' is checked mainly by interrupt() to see
if the rest of proc.c can be called safely (actually the calls are inlined).
If not, the interrupt() is postponed till the end of the system call. This
scheme does not work for the calls in 1) or 2), so explicit locks are
used. (Hmmm, they must be ruining my latency and will have to go.) This
proc.c will be posted with my 386 stuff.
-- 
Bruce Evans		evans@ditsyda.oz.au
D