Types of multitasking

[souradipm]

Hi,
I have managed to get a simple pre-emptive task manager working using stack-switching, but then i noticed that there were multitasking system which clone their address space. I would like to know if there are any differences in functionality and any benefits of address-space cloning. Is it just another way of implementing multitasking or is it a better method to use overall?

Thanks, and please help me sort out my confusion,
souradipm

[Combuster]

I'd call this process management rather than something to do with multitasking. Essentially the only thing the multitasking bit needs to do is select some address space and CPU state and fire that off.

What you are describing is pretty much the equivalent of unix' fork() instruction for creating new processes, which copies the address space and process. Usually with the new process calling a new program which in turn destroys the copied address space in favor of a new one with the new process' contents. The result is also an 1:1 relation of threads and address spaces.

Instead of always cloning an address space you could instead create new address spaces from scratch, create a new address space with corresponding thread from an image stored in an executable file, create new threads in the current address space. There are many imaginable schemes for managing threads and address spaces so its basically a bit of taste how you go about this.

[Love4Boobies]

I thought this thread was going to be something about software vs hardware-based switching. Btw, it was settled that software-based switching is better than current hardware implementatios .

[Schol-R-LEA]

Keep in mind that one of the reasons for the fork() approach in Unix is to make it easier to save memory; only the data segment or pages need be duplicated, the code segment can be used by both processes. However, this combined with the the use of exec() to run new programs can present a problem - you need keep track of whether there is another process mapped to the memory segment, and if it is, you would need to create a new code space for the exec()ed program rather than overwriting the existing one. In any case, the majority of desktop systems today don't run a lot of duplicate processes (as they would have during the multiuser days, or in some modern servers), as there is usually only one user on the system to run programs and threads have become the preferred method of parallelism within a program. Thus, most code sharing these days is done through shared libraries (Dynamically Linked Libraries, in Windows parlance).

[souradipm]

Hi,
Yes, my implementation is software-based. So I guess my implementation is fine, because (correct me if I'm wrong) the fork() type of implementation is just another way of implementing it, but isn't significantly different, just another way to code it.
My stack-switching system has a create_task function which takes an address as a parameter, (which you can get by doing &my_function) and returns the new id of the task, or -1 if memory is exhausted or max_tasks has been reached.
I guess I can keep my task management, because I don't want to go through implementing it again, and I guess it's good to be different

~souradipm

[Love4Boobies]

I was talking about hardware vs software context switching, not fork(). fork() is the UNIX way of creating a new process (explained above).