Are callbacks guaranteed to run consecutively?

Mark,

What is nearly irrelevant is this thread, as we are simply rehasing spinlock design
issues that were well understood and resolved in the industry 20 years ago.

Sad enough, but this is true, and,unfortunately, not only for the spinlocks…

Earlier on this thread Don provided a quotation saying that “OS research is dead”. Indeed, it looks like everything that can be possibly invented in this field has been already invented- no matter what you do, you are always going to get a standard reply “It has been done…”. You may have some seemingly brilliant idea, but after doing some research you are more than likely to discover that this “brilliant” idea had been already tested around 30 years ago and got discarded because it turned out worthless…

Anton Bassov

From my own memory - which admittedly is going after all these years - I can
remember two examples of queuing interrupts at hardware level: the Univac
418 III and the Sperry DCP 20/40. I also heard that the Univac 494, a great
realtimer of its age, did not interrupt, but I’m totally ignorant of the
mechanisms they used. I remember however that airlines such as SAS used a
three-494 system for many years to do their reservations, configured in a
failsafe configuration of two redundant live systems and a third acting as a
hot standby in case either of the other two malfunctioned.

I do not remember the details of the 418 III any longer, this was back in
the 70’s and I didn’t personally work with that system. The machine was a
realtimer, designed to handle high volume transaction applications such as
airline reservations, and it queued interrupts at its peripheral processor.

I did however work my fair share with the DCP machines. The system’s I/O
processors handled interrupts totally in hardware. The programmer would
write the equivalent of an IBM/360 channel program, which directed the
specific processor in its bare i/o function. The hardware would queue
interrupts to hardware queues, created and maintained in memory.

The DCP/40 had two processors, which also recognized the hardware queues at
architectural level. Each hardware queue had what we called a “Software
Attention Item” on its header, and also a “Target Queue”. A processor could
“arm” the queue: this meant that whenever an item was added to the queue,
the Software Attention Item would be queued by the hardware into the Target
Queue, also pre-specified in the queue’s header. That queue could also be
armed with its own attention item, so, an interrupt could trigger a whole
tree of queue updates, all by the hardware and transparent to the OS.

For example, I could have multiple terminal queues feeding a central service
queue through its attention item. I could maintain a tree of queues to
properly route messages. I could have a Uniscope terminal’s queue to point
its Software Attention Item to the OS’s dispatch queue: when the interrupt
came, the I/O processor would queue it into the armed queue, which would
direct the processor to enqueue the SAI into a dispatch queue, which had the
effect of scheduling the equivalent of a DPC, totally by hardware,
transparent to the programmer and subarchitectural to the OS. The programmer
didn’t have to write an ISR, except for the few lines of code to direct the
I/O processor; device drivers basically didn’t exist, it was child’s play to
write an IOP program, a few lines would do; and DPCs were dispatched by
hardware.

The processor had instructions to enqueue and dequeue items, and queue
descriptors were kept in tables not unlike today’s GDT, LDT and IDT. The
processor had a CQM instruction - check queue multiple - which could extract
the highest priority item from an array of queues. This was hw-implemented
priority queues, which we used in the OS dispatcher. At one point of time a
group of people in our lab came up with a new OS - it was called “Monitor” -
and its core OS designer, a personal friend of mine, was proud that the path
through his OS dispatcher consisted of no more than 15 machine instructions.

That’s what I mean when I say that interrupts are better queued - and
serialized - at the APIC. The current APIC cannot do it, but that’s the
direction I believe its development should head.

By the way, the DCP/40 first came out in 1978 or 1979, if I remember. That’s
30 years ago. By comparison, the i386 architecture is some 10 years younger.

Alberto.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Saturday, December 29, 2007 2:28 PM
Subject: RE:[ntdev] Are callbacks guaranteed to run consecutively?

>
>> If the interrupt is queued at the apic, irqls become a hardware-only
>> concern.
>> No need whatsoever to bring the concept into the OS: the interrupt
>> prioritization is naturally ordered by the hardware,
>
> Sorry, but how on Earth is local APIC going to know whether it should
> queue an interrupt or raise it straight away if the OS gives up the
> responsibility of changing IRQL by writing to the local APIC’s TPR??? Are
> you sure you understand what you are talking about???
>
> Anton Bassov
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

A barebones spinlock uses a bus-locking instruction to do one single
read-modify-write access to memory, and loops on the result of that
instruction. Adding a locked acquisition and an extra variable to the loop
makes it no longer barebones. Examples of a barebones spinlock:

while(CompareAndReplace(memory, true));
while(Bit-test-and-set(bit, true));

Each requires two machine instructions: a test and a jump. The corresponding
lock release requires one instruction, and no lock. The test is
self-synchronized by the hardware, the jump’s freewheeling, and there’s no
requirement of atomicity that encompasses both test and jump. The lock
prefix, if required, is part of the test instruction itself. I suspect that
i386 designers didn’t automatically lock the bus in instructions such as
cmpxchg or xadd to avoid the ensuing bus overhead when such instructions are
used in contexts that aren’t sensitive to SMP interference, and to not incur
in the consequent decrease in instruction latency and hence performance.

Note that the test locks the bus for the duration of the read-modify-write,
but between the test and the next test the bus is available. Granted, the
processor is so much faster than the bus that the performance hit on the bus
throughput is real, but then, you can easily do something like

while (CompareAndReplace(memory, true)) delay(n);

where delay can be some cacheable memory read loop, which frees the bus for
other people to use. We’re already stalling the processor anyway, so, the
issue is, is it more profitable to stall the processor or to stall the bus ?
This is, incidentally, one of the things that the author of that paper
suggested, together with exponential backoff: the “n” in the delay(n) is
randomized to some statistical distribution.

The alternative is a test-and-test-and-set loop, which is slightly more
complex:

while (memory); while (CompareAndReplace(memory,true) { while (memory); }

Which replaces the read-modify-write with a read, and that should decrease
the bus overhead by alleviating the MESI protocol overhead. This can be
implemented in machine code, for example,

top:
test memory, 1
jnz top
lock bts memory, 1
jnz top

Read Gregory Andrews’s excellent OS book if you want more details. And
before anyone pooh-poohs any of these ideas, I say, go and measure it.
Publish a paper. Be peer-reviewed. Then we’ll talk!

Alberto.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Saturday, December 29, 2007 2:06 PM
Subject: RE:[ntdev] Are callbacks guaranteed to run consecutively?

>> You can use xchg to implement a spinlock, even though it doesn’t set the
>> flags.
>
> Sure - after all, this instruction locks the bus (you don’t have to even
> prefix it with LOCK - if will assert #LOCK signal anyway). However, the
> whole thing is, again, based upon bus-level locking at the hardware level,
> and, according to you, everything that relies upon bus-level locking is
> already not a “bare-bone spinlock”. Therefore, the question is still
> open - what is a “bare-bone spinlock” in your understanding???
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

If only the ideas that were thrown out were “worthless”, in most cases they
were thrown out because they did not match the Multics/Unix/Posix model of
OS’es. In some cases they were thrown out by pure ignorance.

An example (fortunately with a happy ending) was the C++ standards committee
spent 3 years (probably close to 10 man years) in the mid-90’s arguing on
whether exceptions should be restartable it ended when a paper from 1978
that showed that all optimizations have to be disabled in the face of
restartable exceptions (note: Microsoft’s SEH is actually unsafe since the
compiler does not handle this correctly).

Consider all the things that were thrown in the trash heap and now with
differring names but many times the same mistakes are being reviseds.
Intel pushed the model the CPU handles everything, denouncing the concept of
I/O processors etc, now we have smarter devices since that many interrutps,
etc are now known to be bad.

Every one knows that file-systems are tree structured, but in the late
70’s/early 80’s there was a lot of research on file systems that were not
and had tags (or attributes). The concept was that files would be
classiffied (various models on how) and that you could choose views (similar
to a database view) to see only files related to a project for instance.
Security was built in with the tags also, i.e. you needed an attribute to
access a file (or even know it was there). Nowadays we have desktop search
to locate the relavent data, and track it.

Multi-stage programming, back in the mid-70’s when computers were expensive
there was an idea of using cheap computers for the front end of a program,
then computers of differring capabilities to handle each stage of a program.
The computer and chip vendors were pushing more power so helped mark this as
bad tecnnology, and stop reseach into programming based on stages and how to
tackle problems as streams of data. Now, Intel and others are pouring tons
of money into figuring out how to decompose programs for use on multi-core
processors.

The list goes on, the current model of the PC and the OS is the one that won
the marketing and price war, not nessecarily the best technical solution.
The challenge is that we are now so rooted in the current infastructure that
many of these ideas, will be impossible to adopt.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Mark,
>
>> What is nearly irrelevant is this thread, as we are simply rehasing
>> spinlock design
>> issues that were well understood and resolved in the industry 20 years
>> ago.
>
> Sad enough, but this is true, and,unfortunately, not only for the
> spinlocks…
>
> Earlier on this thread Don provided a quotation saying that “OS research
> is dead”. Indeed, it looks like everything that can be possibly invented
> in this field has been already invented- no matter what you do, you are
> always going to get a standard reply “It has been done…”. You may have
> some seemingly brilliant idea, but after doing some research you are more
> than likely to discover that this “brilliant” idea had been already tested
> around 30 years ago and got discarded because it turned out worthless…
>
> Anton Bassov
>

>If only the ideas that were thrown out were “worthless”

Everything on this thread has been worthless. Everyone knows the correct
implementation of a spinlock is:

SPIN: BBSSI #0,LOCK,SPIN

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Sunday, December 30, 2007 7:37 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Are callbacks guaranteed to run consecutively?

If only the ideas that were thrown out were “worthless”, in most cases they
were thrown out because they did not match the Multics/Unix/Posix model of
OS’es. In some cases they were thrown out by pure ignorance.

An example (fortunately with a happy ending) was the C++ standards committee
spent 3 years (probably close to 10 man years) in the mid-90’s arguing on
whether exceptions should be restartable it ended when a paper from 1978
that showed that all optimizations have to be disabled in the face of
restartable exceptions (note: Microsoft’s SEH is actually unsafe since the
compiler does not handle this correctly).

Consider all the things that were thrown in the trash heap and now with
differring names but many times the same mistakes are being reviseds.
Intel pushed the model the CPU handles everything, denouncing the concept of
I/O processors etc, now we have smarter devices since that many interrutps,
etc are now known to be bad.

Every one knows that file-systems are tree structured, but in the late
70’s/early 80’s there was a lot of research on file systems that were not
and had tags (or attributes). The concept was that files would be
classiffied (various models on how) and that you could choose views (similar
to a database view) to see only files related to a project for instance.
Security was built in with the tags also, i.e. you needed an attribute to
access a file (or even know it was there). Nowadays we have desktop search
to locate the relavent data, and track it.

Multi-stage programming, back in the mid-70’s when computers were expensive
there was an idea of using cheap computers for the front end of a program,
then computers of differring capabilities to handle each stage of a program.

The computer and chip vendors were pushing more power so helped mark this as
bad tecnnology, and stop reseach into programming based on stages and how to
tackle problems as streams of data. Now, Intel and others are pouring tons
of money into figuring out how to decompose programs for use on multi-core
processors.

The list goes on, the current model of the PC and the OS is the one that won
the marketing and price war, not nessecarily the best technical solution.
The challenge is that we are now so rooted in the current infastructure that
many of these ideas, will be impossible to adopt.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Mark,
>
>> What is nearly irrelevant is this thread, as we are simply rehasing
>> spinlock design
>> issues that were well understood and resolved in the industry 20 years
>> ago.
>
> Sad enough, but this is true, and,unfortunately, not only for the
> spinlocks…
>
> Earlier on this thread Don provided a quotation saying that “OS research
> is dead”. Indeed, it looks like everything that can be possibly invented
> in this field has been already invented- no matter what you do, you are
> always going to get a standard reply “It has been done…”. You may have
> some seemingly brilliant idea, but after doing some research you are more
> than likely to discover that this “brilliant” idea had been already tested

> around 30 years ago and got discarded because it turned out worthless…
>
> Anton Bassov
>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

“Dan Kyler” wrote in message news:xxxxx@ntdev…
> >If only the ideas that were thrown out were “worthless”
>
> Everything on this thread has been worthless. Everyone knows the correct
> implementation of a spinlock is:
>
> SPIN: BBSSI #0,LOCK,SPIN
>
> - Dan.

Funny, since that is exactly what was discovered to be poor with the MESI
bus protocol. It pounds the system terribly and hurts performance. Many
systems do the locked instruction followed by tests without the lock
instruction until conditions are met, then try the lock instruction again.

Of course I was talking about more than just spin locks just as the
discussion started else where and devolved to spin locks.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

> A barebones spinlock uses a bus-locking instruction to do one single

read-modify-write access to memory,

What is “single read-modify-write access”??? This kind of thing is just infeasible in itself - at the hardware level you have, first, to read the variable and save its current state, and, second, to modify it. Although it can get done with a single instruction, execution of this instruction will internally involve at least two accesses to the target memory location. Therefore, if you want this operation to be consistent on MP system, it has to be done with #LOCK signal asserted - as I already told you few times, there is just no way to implement a spinlock if the target hardware does not support bus-level locking. It looks like my efforts were not wasted - finally you seem to admit that, in order to make the whole thing work, the target instruction has to lock the bus…

Adding a locked acquisition and an extra variable to the loop makes it no longer barebones.

What is the difference between saving the result/ condition in the second variable ( if you use XADD, XCHG, etc) and in EFLAGS (if you use BST)??? The only difference is that the former offers you a bit more flexibility, so that you can add some improvement ( for example, make sure spinlocks are granted in the same order they were requested) to your implementation. Is it the thing that makes a spinlock implemented this way not “bare-bone” any more??? If this is the case, what about polling a variable as a simple read and trying test-and-set only when it is clear??? Is it not a “bare-bone” spinlock either??? In such case I understand what the term “bare-bone” means - it is just the other way of saying “naively-implemented”…

Examples of a barebones spinlock:
while(CompareAndReplace(memory, true));
while(Bit-test-and-set(bit, true));

It looks like my understanding of the term “bare-bone” is absolutely correct - if the above examples use LOCK prefix at the machine level, they put absolutely unnecessary pressure on the bus, and if they don’t use LOCK prefix, they are just not going to work. In such case all I can say is “It looks like my sample implementation of a spinlock earlier on this thread is (hopefully) not that bare-boned”…

[begin quote]

top: test memory, 1
jnz top
lock bts memory, 1
jnz top

[end quote]

The above code just shows us how KeAcquireSpinlock() works. This is exactly what .KeAcquireSpinlock() does - it polls the variable in a “normal” test loop, and proceeds to locked test-and-set only when it get cleared, thus avoiding unnecessary pressure on the bus…

Anton Bassov

> Everything on this thread has been worthless. Everyone knows the correct

implementation of a spinlock is: SPIN: BBSSI #0,LOCK,SPIN

Well, as far as you are concerned, this thread is, indeed, just a wasted effort- you just did not bother yourself with reading it anyway. If you read it, you would have never made your post, in the first place - on quite a few occasions it has been mentioned on this thread that spinlock implementation that you have provided is really naive, because it puts absolutely unnecessary pressure on the bus…

Anton Bassov

Anton, get a damn life. I doubt you even recognize the assembly language I
wrote there, so you have no clue what hardware it runs on, and therefore
have no clue about the bus pressure. Or perhaps just have no clue.

As for wasted effort, this is a Windows list and spinlocks are already
implemented. Arguing about the “best implementation” is clearly wasted
effort. You don’t control the implementation. Only Alberto does, because
he writes his Windows drivers without using any Windows kernel routines. I
don’t think he uses an assembler either–he just types in the opcodes in
hex.

But just to make YOU happy Anton, how about this one:

SPIN: BBS #0,LOCK,SPIN
BBSSI #0,LOCK,SPIN

I hope that relieves the pressure on your bus.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Sunday, December 30, 2007 2:39 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Are callbacks guaranteed to run consecutively?

Everything on this thread has been worthless. Everyone knows the
correct implementation of a spinlock is: SPIN: BBSSI #0,LOCK,SPIN

Well, as far as you are concerned, this thread is, indeed, just a wasted
effort- you just did not bother yourself with reading it anyway. If you
read it, you would have never made your post, in the first place - on quite
a few occasions it has been mentioned on this thread that spinlock
implementation that you have provided is really naive, because it puts
absolutely unnecessary pressure on the bus…

Anton Bassov


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

> I can remember two examples of queuing interrupts at hardware level:

the Univac 418 III and the Sperry DCP 20/40.

You can surely add x86 to the above list - indeed, CPU’s local APIC may either queue interrupts
( if current IRQL >= target interrupt priority) or fire them straight away ( if current IRQL < target interrupt priority). Furthermore, x86 designers could have extended this concept even further,
effectively eliminating any need for TPR - they could make the local APIC remember priority of the last interrupt that it has raised, and pend all interrupts of lower priority until its handler issues EOI, so that only interrupts of higher priority can interrupt ISR execution.
However, would it be a good idea??? More on it below…

That’s what I mean when I say that interrupts are better queued - and serialized - at the APIC. > The current APIC cannot do it, but that’s the direction I believe its development should head.

Look - the very purpose of TPR is to allow OS software to tell the local APIC (and not necessarily in context of ISR, which is very important) that it does not want it to fire interrupts below some certain priority at the moment. Probably, Windows just took the concept of IRQL a way too far, but it does not mean that the OS should not have a possibility to disable interrupts below some certain priority if it needs to do so. Therefore, what you have proposed above is *NOT* some kind of “revolutionary” idea, as you may be thinking - instead, it is a huge step backwards…

By the way, the DCP/40 first came out in 1978 or 1979

… and in less than respectively 23 (in Europe) and 32 (in the US West Coast) hours it will be already the year 2008. Do you really want to go 30 years back in terms of technology???

Anton Bassov

> Anton, get a damn life.

I am going to try my best…

I doubt you even recognize the assembly language I wrote there,
so you have no clue what hardware it runs on,

I somehow presume it must be VAX…

As for wasted effort, this is a Windows list and spinlocks are already implemented.
Arguing about the “best implementation” is clearly wasted effort. You don’t
control the implementation. Only Alberto does, because he writes his Windows
drivers without using any Windows kernel routines.

What makes you believe that Alberto ( or me, or any other thread participant) does nothing, apart from writing Windows drivers??? Some participants may well be in control of spinlock implementation, although not under Windows. Furthermore, some participants of this thread may be controlling spinlock implementation even under Windows - Jake is the very first example that comes to my mind…

I don’t think he uses an assembler either–he just types in the opcodes in hex.

Probably, you are right - it depends on what he does…

For example, if he writes a code that makes a transition from the real mode to the protected one or vice versa, he has no option, other than presenting a far jump instruction as a hex data - otherwise, NASM (or whatever assembler he uses) is not going to generate the code properly.
There are some other situations when inserting hex data is a code section is really useful.

Please note that all this activity is not incompatible with writing Windows drivers. For example, one may be writing his own small OS that gets loaded before Windows and controls all access to the actual hardware, delegating the job to Windows whenever it believes it should do so, while still maintaining its own control over everything that happens. Needless to say that Windows is blissfully ignorant of the whole thing - it believes that there is nothing in between itself and the actual hardware - the only one who understands what is going on is your own driver that runs under Windows and communicates with your actual OS via some “not-so-obvious” channels.

Therefore, don’t put the participants of this thread too low - there is no guarantee that none of us does anything, apart from writing Windows drivers in KMDF…

Anton Bassov

Come on, guys! Where’s the Hitler reference?!

Oops…

Irrelevant, Hitler was a Mac user…

Matt
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, December 31, 2007 2:08 AM
Subject: RE:[ntdev] Are callbacks guaranteed to run consecutively?

> Come on, guys! Where’s the Hitler reference?!
>
> Oops…
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

We have reached a stage in which vastly superior kernel developers of the
new age have risen thus far above that they provoke nothing but jealousy
from the tarnished MVPs and their flock. Coincidentially it’s exactly the
right time of year, so I suggest you should just go claim and proclaim your
awards with ablution. Their tarnishment, the deficit of their pageantry,
well … “as long as they know for them it’s just dance, smile or quit”.
Happy new year guys.

/Daniel

wrote in message news:xxxxx@ntdev…
> Therefore, don’t put the participants of this thread too low - there is
> no guarantee that none of us does anything, apart from writing Windows
> drivers in KMDF…
>
> Anton Bassov
>
>

The i386 isn’t that much younger either, and it sits on top of the i286
which is even older. According to

http://www.intel.com/museum/online/hist_micro/hof/

the 286 is vintage 1982, and the 386 was issued in 1985. Given that the
DCP/40 came out in 1979 or so, we’re talking about technologies that more or
less date from the same age bracket. In fact, the segmented design present
in the i286 and i386 was already present in the DCPs, and it came from even
older architectures.

We’re all dealing with 30 year old architecture and technology.

Alberto.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Sunday, December 30, 2007 7:11 PM
Subject: RE:[ntdev] Are callbacks guaranteed to run consecutively?

> … and in less than respectively 23 (in Europe) and 32 (in the US West
> Coast) hours it will be already the year 2008. Do you really want to go 30
> years back in terms of technology???

> the 386 was issued in 1985.

Although protected-mode x86 architecture is, indeed, is based upon 386 (and real-mode one is right on 8086), it does not mean that all modern x86 processors are still the same good old 386. As far as out discussion about APIC is concerned, it is just 10- year-old technology - IIRC, support for APIC turned up only on PentiumPro. What you propose is pretty much moving back to PIC, i.e. back to the architecture where interrupt priority is implied by IRQ - you want to remove all flexibility that APIC offers. This is why I said that the thing you propose is a huge step backwards (BTW, you can do it purely in software - just disable APIC via IA32_APIC_BASE MSR, and you will be unable to make any use of it until CPU reset…)

Anton Bassov

> We have reached a stage in which vastly superior kernel developers of the new age

have risen thus far above that they provoke nothing but jealousy from the tarnished
MVPs and their flock. Coincidentially it’s exactly the right time of year, so I suggest
you should just go claim and proclaim your awards with ablution. Their tarnishment,
the deficit of their pageantry, well … “as long as they know for them it’s just dance,
smile or quit”. Happy new year guys.

Absolutely pointless, unmotivated and totally stupid attack …

Anton Bassov

The APIC is incidental to this thread. Shared memory multiprocessor
technology predates the APIC by quite a few years. The PIC was a simple
minded device from the hobbyist era, but the APIC as a technology doesn’t
over much more than your typical 60’s or 70’s mainframe alread had.

Machines today are big and fast, but their architecture is old. Sorry,
Anton, I for myself do not believe that our machines today are that much
better from what they used to be 30 years ago. And the age tag on our OS’s
matches. The machines are bigger and faster, but the credit goes to the
solid state guys and to the electronic engineers! Excepting for Object
Orientation, we’re still programming the way we did back in the 70s.

Le plus ca change, le plus c’est la meme chose…

Alberto.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, December 31, 2007 8:52 PM
Subject: RE:[ntdev] Are callbacks guaranteed to run consecutively?

>> the 386 was issued in 1985.
>
> Although protected-mode x86 architecture is, indeed, is based upon 386
> (and real-mode one is right on 8086), it does not mean that all modern x86
> processors are still the same good old 386. As far as out discussion about
> APIC is concerned, it is just 10- year-old technology - IIRC, support for
> APIC turned up only on PentiumPro. What you propose is pretty much moving
> back to PIC, i.e. back to the architecture where interrupt priority is
> implied by IRQ - you want to remove all flexibility that APIC offers. This
> is why I said that the thing you propose is a huge step backwards (BTW,
> you can do it purely in software - just disable APIC via IA32_APIC_BASE
> MSR, and you will be unable to make any use of it until CPU reset…)
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

> I for myself do not believe that our machines today are that much better

from what they used to be 30 years ago. And the age tag on our OS’s matches.
> The machines are bigger and faster, but the credit goes to the solid state
guys and to the electronic engineers!

From purely conceptual point of view, I fully agree with you here - indeed, as it has already been mentioned earlier on this thread, all OS concepts that we use today seem to be originated in 60s-70, so that you are very unlikely to invent something that is basically new and unheard of in computer science. The thing is, advances in electronics just made it possible for hardware and OS designers to bring the concepts that in not-so-distant past could be implemented only on the mainframe to the world of PCs and even more primitive devices. Let’s face it - when it comes to computing power, a modern mobile phone beats early 70s mainframe hands down…

However, it has nothing to do with our discussion of interrupt queuing. As it follows from a discussion of splx() on early UNICes earlier on this thread, OS software still had a chance to disable delivery of interrupts below some certain priority, i.e. some logical equivalent of TPR was still present on these hardware architectures. The only reason why it did not exists on PC back then is because the state of micro-electronics just did not allow it at the moment - otherwise, 386 would have undoubtedly provided support for APIC, as well as for logical multiprocessing and 64-bit memory addressing. This is why I say that the thing you propose is a step 30 years back…

Anton Bassov

Attack ? This is not an attack. But then, there is no need for you or anyone
to become my friend for me to recognize his superiority. Generally speaking,
the nasty ones are often the people with something interesting to say.

/Daniel

wrote in message news:xxxxx@ntdev…

> …unmotivated …attack …
>
> Anton Bassov
>