>> what is this program for? you're using multiple threads. i haven't
>> seen anyone suggest this. it has neither the benefits of the
>> multiprocess case nor the single-threaded case. i don't understand.
>
>It's a program to measure the actual cost of context switch (that AFAIK
>is equal for different thread or different processes). The same program
>may be written with shm and fork.
abramo, do you know who larry mcvoy is, or how much work (and money)
went into lat_ctx? if you want to measure the cost of a context
switch, then lat_ctx is the way to do it.
i haven't run your program, so i don't know about the context switch
time being the same. i doubt it. and besides, we're not interested in
just context switch time, its "time from sending a message to when the
receiver is running".
>However I cannot believe you don't see the benefits of a multithreaded
>approach:
>- big improvement for components that can run in parallel on SMP
>machines
nobody wants to even get close to this area right now. this is too
complex and the tradeoffs are very hard to measure and be sure about.
the number of systems where NCPU's is greater than 2 is extremely
small, and i don't believe that the dual systems are best used in this
way if an excellent user experience is the goal.
>- greater crash safety
what? threads don't provide any crash safety. if one thread crashes,
so does the process; if one thread does a pointer walk, it can walk
all over the memory used by other threads.
--p
