Date: Fri, 12 Apr 1996 07:41:06 -0400 (EDT) From: Wong <wong@rogerswave.ca> To: Terry Lambert <terry@lambert.org> Cc: terry@lambert.org, hasty@rah.star-gate.com, roell@blah.a.isar.de, hackers@FreeBSD.org, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <Pine.BSF.3.91.960412071308.4715B-100000@wong.rogerswave.ca> In-Reply-To: <199604111804.LAA04310@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Apr 1996, Terry Lambert wrote: > Sounds like what you want is TQE's with AST's to implement primitive > deadlining (as opposed to implementing real deadlining). That is one way of using AST by some unix box(not just VMS). > > All of the AST mechanisms discussed so far really don't have the > idea of implementing TQE's anywhere in them... even my calls for > kernel one-shots wouldn't make the thread schedulable if there > were other ready-to-run threads (processes) ahead of it in line > that had not consumed their system quantum. > suppose if you have another CPU just wait for that thread and nothing else. i.e. CPU have priority and the kernel is n-queue scheduling and pre-emptive fix priority for process. we don't even need re-entrant kernel. however,thread (OS/2 style) is definitely helping out here. > For what you want, in terms of being able to respond deterministically, > kernel preemption is required. > > Which means kernel reentrancy is required. > > Which means kernel multithreading is required. > > These are all on my list, but they ar a long way off at present, and > much of the required changes are going to have to go in when the > interrupt virtualization goes in for SMP. It's a requirement of > that model that the interrupt service routines be split, and the > absolute minimum amount of work be done at interrupt level, queueing > the actual work for later. This will have the side effect of decreasing > interrupt latency, even in the UP case, since after the queue but > before processing, the system would be reay for another interrupt > (NT does this; so does SVR4 ES/MP and Sequent's OS, as well as Solaris). > I certainly haven't been working on the interrupt code; I've only > been working on the system call entry into the kernel, one of the > three ways in (the third being via exceptions, like page faults or > stack growth). > > I think I've found someone with greater amibitions with shorter time > frames than myself. 8-). <g> actually, if you can recommend me a cheap and good 2-CPU motherboard I might be able to work on it. Ken
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960412071308.4715B-100000>