About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Mon, 29 Jan 2007

Climbing evening.


I've bought myself new climbing shoes - this time I got "La Sportiva" instead of "Boreal", and it looks like my choice was right, although it looks like I got slightly biger size than the best (I have russian 43 foot size, and climbing shoes are usually about 40.5, but with "La Sportiva" it could be even smaller due to the way shoes are designed). I tried several old traces, and failed one of them which although quite complex, but I finished it without major problems before (green 7a in central sector in Skala-city). At the end I tried some jumping I discovered in old trace, but failed again - probably it is due to the new shoes, which are quite different for the feet, or because of the slightly different size, time will show.

/life :: Link / Comments (0)

M-on-N threading library got a homepage.


Here one can find some design ideas and notes compiled from threading blog tag, which you are currently reading.

/devel/threading :: Link / Comments (0)

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)