Hi,
I am planning to do project in Analysis and evalution of posix threads vs win32 threads.
I am actually measuring thread creation time, thread scheduling latency(time taken by scheduler to stop one thread and start another thread), inter-thread communication with mutex.
I am not able to find what kind of more latencies, I can measure.
This is my term project.
Any Ideas are welcome.

1 solution

Solution 1

That's a good question... You've already chosen some things to measure, but since you're measuring performance between two competing implementations of standards, I'd also like to see shared memory access performance when using critical sections instead of mutexes. It's supposed to be faster since it doesn't require going to the kernel, but it be interesting to find out exactly how much faster.

Good luck and please do post as an article when you're done. It's always interesting to see performance statistics for different implementations.

Theorethically, a mutex does not need the kerenl either. Mutex is supposed to be the best of a "spin lock" (requires a hardware atomic test-and-change instruction) and a "semaphore" to queue waiters. If there's no contention for the interlock, a mutex can determine that in a single instruction (test and set) and proceed but if another thread owns the lock then there's a queue to wait in. While "spin locks" are fast when acquiring a lock, they have the downside of chewing up cpu cycles waiting for the contending lock to release it. This can effectively slow down the system when the number of lock contenders is greater than the number of processors / cores available to run them.

I seem to remember reading on msdn that mutexes did go to the kernel, I don't exactly remember the context or anything, but it was their rationale for explaining that critical sections are a better/faster option in most cases (depending on use of course)... but then again, I can't recall what I wore Friday. :)

Well, I'm not exactly sure of Windows NT based kernels so I'll defer to msdn. Mutexes have been around longer than Windows NT and existed before POSIX codified them in a standard. As early as 1970 I was using read/modify/write instructions to do the "fast lock check" part of the mutex followed by a semaphore / queueing operation if the lock was taken. So, that's why I said that in theory, you don't need to involve "a kernel" until you need to block / wait for the release event.