OSDev.org

To clear things up, here are my points please pointout which you disagree with.

1. Dos Has alway Had A basic forum of multi-tasking, eg: TSR.

But if i tried to sells Dos (many yeas ago) as a multi-tasking OS, i would not of got away with it, as i have pointout any interrupt could be said to do the the same as a TSR. So play on words is nogood, Dos is consider in OS terms a single-tasking OS, just like the old xbox is.

2. I say multi-tasking and multi-threading are the same thing with ONE big difference,

Multi-threading is within a program, multi-tasking is within a OS, that means i can easy hook into the timer IRQ, from within my program, switch threads etc.
Even if that program is running on a single tasking OS like Dos or the old xbox.

3. We are talking in this case about the xbox, now as it has no memory management, (other than what the program provides ), how can you have multi-tasking, its easy to have multi-threading controlled by the program and in charge of its own memory management.

here are my responses:

1)your almost correct... except where you said that comment about interrupts -- TSRs are a way for applications to work with dos to use the interrupts -- TSRs do use the interupts -- that is the only way they ever get any execution time -- i didnt say it was done well, i just said it was done -- TSR is simply a way of telling DOS not to remove it from memory or overwrite the memory it is using, for it to actually continue running, it had to hook the interrupts

2)

Multi-threading is within a program, multi-tasking is within a OS

all major OSs would disagree with this one, as the OS (not the program) provides the switching code for handling threads...

also, as i stated, this requires that you define the word 'program' -- my position is that there is no definition for the word 'program' -- for (a very simple) example:by your definition then, is office several programs using multi-tasking? or 1 program using multi-threading...

that means i can easy hook into the timer IRQ, from within my program, switch threads etc.

most OSs (including XBOX) do not allow this directly (you could however simulate it using a timer event, but with extremely poor results) -- attempting to do this, will result in a disaster with far worse performance than if your application was single-threaded -- most OSs provide a syscall for you to use to create 'threads' in a very similar manner to how you create 'processes' -- however its usually (though not always) treated as a very lite-weight process, and lacks many of the protections from other threads owned by the same process (how much isolation, depends on the particular OS -- and some treat it exactly the same as a completely separate process

Even if that program is running on a single tasking OS like Dos or the old xbox.

again i claim that XBOX is not a single-tasking OSs (XBOX claims to be because they do have a reference for defining multi-tasking -- windows, where processes in xbox are treated similarly to the way windows handles threads)

and while i would not consider DOS to be a multi-tasking OS, it is certainly not limited from using multi-tasking (though the application provides the switch-code)


3)

We are talking in this case about the xbox, now as it has no memory management, (other than what the program provides ), how can you have multi-tasking, its easy to have multi-threading controlled by the program and in charge of its own memory management.

multi-tasking doesnt require memory management at all (and while i havent looked at it, i would guess that xbox does have memory management -- just not virtual memory) -- there is no requirement for multi-tasking OS to provide memory management -- that is only necessary for a multi-purpose OS, which cannot deturmine at compile-time exactly what processes will be running -- where a special-purpose OS (like XBOX) doesnt have this same restriction (at compile-time, the identity and memory usage of every process is known)

btw: DOS did have memory management (just not hardware-enforced memory management)

however multi-tasking doesnt require memory management -- its only requirement is that there are more than 1 piece of code executing which may be switched at some point -- in fact multi-tasking doesnt even require access to a clock at all -- for example, most DOS TSRs didnt hook the clock interrupt at all -- only the keyboard interrupt for many of them, and they would only get CPU time when the user pressed the appropriate shortcut key

JAAman wrote:here are my responses:
also, as i stated, this requires that you define the word 'program' -- my position is that there is no definition for the word 'program' -- for (a very simple) example:by your definition then, is office several programs using multi-tasking? or 1 program using multi-threading...

My answer to this is, office is 1 program, using multi-threading.

most OSs (including XBOX) do not allow this directly (you could however simulate it using a timer event, but with extremely poor results) -- attempting to do this, will result in a disaster with far worse performance than if your application was single-threaded -- most OSs provide a syscall for you to use to create 'threads' in a very similar manner to how you create 'processes' -- however its usually (though not always) treated as a very lite-weight process, and lacks many of the protections from other threads owned by the same process (how much isolation, depends on the particular OS -- and some treat it exactly the same as a completely separate process

Now this is where the miss understand is, you are thinking in terms of multi-threading on a multi-tasking OS, i am thinking in terms of multi-threading on a single-tasking OS, There is a difference.
See the the following xbox spec

1. While the Xbox kernel is based on the NT/Windows 2000 kernel, it's extremely lean.
2. There's no virtual memory paging, and only a single process is allowed (though that process can spawn multiple threads).
3. The entire kernel fits into 150KB--far less than the 1MB original goal.
4. The development library is polling-based rather than event driven (unlike Windows). This was due directly to feedback from game developers.
5. The game owns the hardware--it runs in ring 0, and has direct access to all hardware (including CPU and graphics).
6. Memory allocation is the responsibility of the app--there's no front-end memory allocation.

Now if you take alook at number 5.

The game owns the hardware--it runs in ring 0, and has direct access to all hardware (including CPU and graphics).

You will see that in the Xbox you have FULL access, this includes the time IRQ.
Also if you read part 6

Memory allocation is the responsibility of the app--there's no front-end memory allocation.

You will see the app (game) is responsible for memory management.

So try to think of how you would do multi-threading, in a single-tasking environment, which the Xbox is, i think you are seeing multi-threading in terms of a OS like linux.

Dex wrote:

1. While the Xbox kernel is based on the NT/Windows 2000 kernel, it's extremely lean.
2. There's no virtual memory paging, and only a single process is allowed (though that process can spawn multiple threads).
3. The entire kernel fits into 150KB--far less than the 1MB original goal.
4. The development library is polling-based rather than event driven (unlike Windows). This was due directly to feedback from game developers.
5. The game owns the hardware--it runs in ring 0, and has direct access to all hardware (including CPU and graphics).
6. Memory allocation is the responsibility of the app--there's no front-end memory allocation.

Now if you take alook at number 5.

The game owns the hardware--it runs in ring 0, and has direct access to all hardware (including CPU and graphics).

You will see that in the Xbox you have FULL access, this includes the time IRQ.

Just because games run in ring 0 and can have full reign of the hardware, doesn't mean that they actually do. Otherwise, what would be the point of using the NT kernel in the first place? Might as well let game developers write to the bare metal...

What this really means is that games run in kernel-mode, just like device drivers, but the kernel itself is still there. All the same rules of writing NT drivers still apply (e.g. -- there are certain kernel calls you can't make if the IRQL is too high). This also means that the kernel itself is responsible for thread switching.

So try to think of how you would do multi-threading, in a single-tasking environment, which the Xbox is, i think you are seeing multi-threading in terms of a OS like linux.

No, I think we're thinking of how the Xbox works in terms of the NT kernel, which it's based on, and which supports multi-threading, just like Windows does.

You can call it blue-cheese-tasking for all I care, but to compare the old Xbox to DOS is a gross misrepresentation. I would argue that the complexity of implementing multi-threading is much greater than the complexity of implementing something like TSRs (which is IMO the kind of information that the OP was looking for in the first place before you decided to summarily re-define what "single-tasking" means).

Processes have their own address space. Whether or not that space is isolated is irrelevant. If a thread is supposed to run in a certain address space then it is part of the process to whom that address space belongs. A process is a set of threads with the same address space and a thread is a stream of execution in the processor. In order to run a process must have one thread that is doing the running.

iammisc wrote:Processes have their own address space. Whether or not that space is isolated is irrelevant. If a thread is supposed to run in a certain address space then it is part of the process to whom that address space belongs. A process is a set of threads with the same address space and a thread is a stream of execution in the processor. In order to run a process must have one thread that is doing the running.

then if that is the case, how do you define 'address space' because we are talking about a system where every process is in the same address space -- without isolation, definition of 'address space' is meaningless, because all processes share the same address space -- the question is, are threads and processes different if they are both handled exactly the same way?


and some OSs (including mine, and brendens iirc) do not use exactly the same address space (iirc brenden uses a separate address space for threads, and i use a modified address space)