Q: is there a bug in sleep10() ?

Thread View: comp.os.xinu

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Bruce M. Walker Sun, 13 Dec 1992 19:55

#165

Author: Bruce M. Walker
Date: Sun, 13 Dec 1992 19:55

37 lines
1845 bytes

Here is a question about a possibly subtle problem in interrupt
handling in XINU:

Early in the text [1], the importance of preventing kernel structures
from being corrupted by conflicting processes is stressed.  The notion
of surrounding critical regions with

    char ps;
    disable(ps);
    ...              /* critical code */
    restore(ps);

is discussed in section 5.2 "System Calls".

The area I'm interested in is resched() and ctxsw().  Examination of
the code reveals that in almost all cases, the functions calling
resched() do so when the interrupts are off (ie: inside of
disable/restore sections).

Except: in the SYSCALLs "sleep()" and "sleep10()" from sections 10.5
and 10.6, resched() is called directly from these functions, and
*with the interrupts enabled*!

Now the question:  am I missing something, or does this not violate the
rules about protecting the pentry structures?  What would happen if an
interrupt went off while we're executing inside ctxsw(); that is, when
we're half way through exchanging registers from one process context to
the next?  Wouldn't this result in complete havoc?

---
[1] my reference copy is: "Operating System Design: The XINU Approach",
    Comer; 1984

--
"Eventually, I decided that thinking was not getting me very far and it
 was time to try building."           -- Rob Pike, The Text Editor sam
      bmw@isgtec.com   [ ...!uunet.ca!isgtec!bmw ]  Bruce Walker

Re: Q: is there a bug in sleep10() ?

#166

Author: Bruce M. Walker
Date: Mon, 14 Dec 1992 02:04

16 lines
1313 bytes

In article <3854@isgtec.isgtec.com> bmw@isgtec.com (Bruce M. Walker) writes:
> in the SYSCALLs "sleep()" and "sleep10()" from sections 10.5
> and 10.6, resched() is called directly from these functions, and
> *with the interrupts enabled*!

Well I just found support for my assertion that the Comer '84 code for
sleep10()/sleep() is busted:  in a later version of XINU code that I
had received from John Reed (johnr%pacdata.uucp@ucsd.edu), sleep10() and
sleep() have both been patched so that resched() is called from within
disable(ps)/restore(ps).  So I think I can rest assured that indeed,
resched() and ctxsw() must be executed atomically, as I thought.

--
"Eventually, I decided that thinking was not getting me very far and it
 was time to try building."           -- Rob Pike, The Text Editor sam
      bmw@isgtec.com   [ ...!uunet.ca!isgtec!bmw ]  Bruce Walker

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads