Re: how do threads work?
From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 11/21/05
- Next message: Kasper Dupont: "Re: how do threads work?"
- Previous message: Kasper Dupont: "Re: how do threads work?"
- In reply to: Andersen: "Re: how do threads work?"
- Next in thread: Andersen: "Re: how do threads work?"
- Reply: Andersen: "Re: how do threads work?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 21 Nov 2005 00:16:46 +0100
Andersen wrote:
>
> Enrique Perez-Terron wrote:
>
> > A process cannot consider to switch task unless the flow of instructions
> > brings it to a function that does such deliberations. While in the middle
> > of computing pi to one million decimals, the flow of instructions does
> > not get near any such function. To solve this, the process can ask the
> > kernel for a little help, in the form of regular timer signals.
>
> Right. Though I am curious how that would be implemented on a IA32 arch
> (Interrupts?).
No it is not interrupts, it is signals. There are quite some
similarities but they are at different abstraction levels.
Interrupts are implemented by the hardware such that the
kernel can make use of them. Signals are implemented by the
kernel such that applications can make use of them.
What the kernel does to deliver a signal involes modifying
the user mode stack. It creates a new stack frame saving all
registers and signal masks. It also arranges for a special
system call to be called on return from the handler. This
return from signal system call will then restore user mode
registers from the saved values.
The kernel doesn't care if you switch stack causing such
signal handlers to return in an order completely unrelated
to the one they were invoked. It will just restore what it
is told to restore (it is user state we are dealing with, so
the kernel has nothing to worry about).
>
> Would it not be quite simple to have multiple stacks, save their stack
> pointers on the heap of the thrd lib, and when context switching make
> sure that the right stack pointer is used poiting to the right place?
Yes, that is exactly how switching works. The most tricky
part often prove to be how to create an initial stack such
that switching to a newly created thread works.
>
> Why is this a problem if your a using signals to preempt? I mean why
> replace blocking calls. Why not just use the signal, interrupt the
> blocking operation and context switch? Is it problematic to signal in
> the middle of a blocking call?
First of all interrupting the blocking call is not good
enough. You want the CPU to be used for something as soon
as one thread blocks. Say you have an application that have
one CPU bound thrad and one I/O bound thread. The I/O bound
thread blocks in a system call, and the CPU becomes idle.
The CPU bound thread is still waiting for the CPU even
though it is idle, only later while a singal arrives will
the thread be scheduled. But that is not the only problem,
because once the CPU bound thread has got the CPU, obviously
the process is no longer blocked waiting for I/O, so when
whatever hardware it was waiting for has completed, the
process will not notice. Only later when the thread switching
happens again, the I/O bound thread will restart the blocked
system call.
The result will be that both the CPU bound and the I/O bound
thread executes at half the speed of what could have been
achieved. A pure user mode thread implementation solving this
is only possible if the kernel offers some async I/O interface
which can be used instead of blocking calls. then a signal
from the kernel will ensure the library can switch threads
once the I/O bound thread can unblock. This is similar to the
advantages of hardware sending interrupts.
But such a user mode thread implementation is going to be
complicated, and still doesn't take advantage of multi CPU
systems. So one might as well move the entire threading into
the kernel. The kernel already has most of the threading
infrastructure, so it doesn't get significantly more
complicated.
>
> > However, if a program uses a new kind of device, executes some ioctl's that
> > the threading lib authors were not aware of, or that did not even exist at
> > the time, then the threading lib will not have a wrapper for that.
>
> Again, why would it not work as the signal would interrupt this
> unexpected blocking operation?
Like I explained above, a signal interrupting a blocking
system call does not give you a good threading performance.
Besides not all blocking calls are interruptible.
-- Kasper Dupont Note to self: Don't try to allocate 256000 pages with GFP_KERNEL on x86.
- Next message: Kasper Dupont: "Re: how do threads work?"
- Previous message: Kasper Dupont: "Re: how do threads work?"
- In reply to: Andersen: "Re: how do threads work?"
- Next in thread: Andersen: "Re: how do threads work?"
- Reply: Andersen: "Re: how do threads work?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
