|
|
About ::
TODO ::
Blog ::
RSS ::
Old blog ::
Projects ::
GIT ::
Gallery ::
Notes
Mon, 29 Jan 2007
Atomic locks and updated starting route for M-on-N threading model.
After I started to use atomic locks (lock prefix on x86)
instead of semaphores, thread start/empty exec/stop was reduced down
to 0.3 microseconds compared to 14 microsecods for POSIX NPTL
case.
But there are problems.
First one is that I perform initial context setup through signal invokation,
which is at least two syscalls. They are slow.
Another one is that thread is really started only after rescheduling, which
is another signal, so another two syscalls.
Third on is that there must exist different locking primitives - for signal context
and for process context, which must block signals, which in turn adds
additional overhead of sigprocmask() syscall.
After I fixed all above issues (actually not fixed, but confirmed that they must
exist), performance reduced to 9 microseconds compared to 14 microsecods for POSIX NPTL
case for empty thread creation/destruction.
This can be fixed, if I would have created arch-specific getcontext()-like
calls, which would be mutually transformable into signal context information
(existing getcontext() and friends produces different data than
signal context has at least on x86). But I can not right now, since I do not know
enough x86 ABI (I learned a lot for past several days, as you can notice from
this blog, but it is still even remotely not enough).
Currently M-on-N threading model uses ugly arch-specific hacks to start new threads,
which actually are something remotely similar to makecontext().
So, the solution, which will rock M-on-N threading implementation is to
convert or create getcontext() and friends calls which can be used with
signal context information.
But let's Linux motto "release early, release frequently" fly - I plan to release
alpha version today even without syscall substitution support and send it to linux-kernel@ and
libc-hacker@ for review.
/devel/threading :: Link / Comments (0)
Please solve this captcha to be allowed to post (need to reload in a minute): 1 + 32
|