Date: Thu, 11 Apr 1996 11:04:06 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wong@rogerswave.ca (Wong) 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: <199604111804.LAA04310@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.960410201244.3729B-100000@wong.rogerswave.ca> from "Wong" at Apr 10, 96 08:55:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > AST's are easy. It's the stacks they need to run while your program > > is already using your only stack that are annoying. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > why? you can allocate space for each and every process ( thread ) that > want to handle AST. in fact it can be on another CPU. Because AST's are "Asynchronous System Traps", not "Thread Starting Events". You *could* handle events by starting seperate kernel threads (the classical non-segment method of getting multiple real instead of pseudo-stacks), but it would be terrifically inefficient to do it. Further, in VMS (let's be open, if we are talking about AST's), it isn't required, and having to make the code thread-safe is not a requirement. Finally, I think you are confusing AST's and CV's (Condition Variables), which are also settable as a result of the scheduled event completing. The difference is that ina threaded process, I would need an ITC mechanism, like a CV. With a classical AST, all I need is a volatile variable. > > Queued event delivery shouldn't have any impact on how RT > the system AST are delived to those process that registered to handle a > given interrept. in a user space. > > > is or isn't (maybe I just can't see what you mean...). Message > > passing does not a R.T. system make, in my book... > > well, I was just a bite vague on this, I meant besides the regular > textbook schedule on R.T. pre-emptive,fixed priority etc..., this even I > can do even when I am awake. > > but for for applications, you want to have a process run on a specific > CPU alone wait for A/D conversion complate, so that the process can > strobe the data in in a _determinestic_ manner. I am not good in > drawing, otherwise, I can show you the exact timing in this. > anyway, in my book, exact timing is R.T. Sounds like what you want is TQE's with AST's to implement primitive deadlining (as opposed to implementing real deadlining). 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. 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-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604111804.LAA04310>