The highlevel API's in AtheOS encouraqe the programmer to write multi-threaded applications. Whenever you open a window, the new window will get it's own thread, and the application object (the objects that inititate the app's connection to the appeserver) normally runs in the main thread(1), so if the application have some long-lasting tasks to do, or a task that is not a direct responce to a message comming to the window or the application object it will have to spawn a new thread for that to. This fine grained threading make's the user interface appear very responsive even when the application is busy. Spreading the load over many thread's like this also make the application scale better on SMP machines.

AtheOS does not only multi-thread user application's, the kernel is fully preemptive with each separate object protected with semaphores. This allow AtheOS to fully utilize all the processors in an SMP machine even when running applications that do foul the kernel to do most of it's work Not only is the kernel muti-threaded but it also allow device drivers, file-system's, network and any other sub-systems to be multi-threaded. The kernel never lock anything before calling into any of it's friends so it's up to each component to decide how fine-grained muti-threading it will allow. F.eks the native file-system will allow an arbitrary number of threads to access the file-system simoultaneously as long as each thread work on separate files. I will propably fix this so multiple thread's can read/write the same file simoultaneously as long as the file-size is not changed (need some kind of "read-only" lock on semaphores first).

Its worth mention that the scheduler in AtheOS has some interesting features that make it sucks a bit more than I like to admitt. First it is a plain round-robin RT scheduler so it does not have any dynamic-priority scheems. This make it very efficient, but is not excactly what you want in a general desktop OS since one high-priority thread can block all lower-priority thread's forever if it never gives up the CPU (on a single-CPU machine that is), or make the machine feel non-responsive if it hogs the CPU for too long. This is seldom a problem though even on single-CPU machines, and is never a problem on my dual-CPU box (which propably is the main reason it have not yet been addresse :). This problem will ofcourse go away when I add support for a more dynamic priority scheem in the scheduler. Seccond it has no scheeme to avoid threads migrating insanly often between CPU's, so if you has one fully busy thread on your dual CPU system you will see that there is about 50% load on each CPU :( Needless to say this cause a bit more L1 (and sometimes L2) cache flushes than defensible. This will also be addressed eventually by trying to keep a thread on the CPU it was last run.

AtheOS does not currently support p-threads, but has its own flexible API for creating and controling threads. I have not looked to closely at the p-thread API, but I guess it should be possible to emulate most of it through AtheOS threads.

1. The main thread is the first thread born in a process, and the one that sneek into the main() function. Except from being the first-born there is nothing special to it compared to other threads spawned during execution.