Posix thread vs win32 thread lantencies

Question

5.00/5 (2 votes)

See more:

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.

Posted 10-Sep-12 3:13am

chavali chaitanya

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Albert Holguin · Answer 1 · 2012-09-10T07:51:00

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.

Posted 10-Sep-12 7:51am

Albert Holguin

Comments

Chuck O'Toole 10-Sep-12 15:49pm

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.

Albert Holguin 10-Sep-12 17:04pm

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. :)

Chuck O'Toole 10-Sep-12 17:57pm

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.