pthread_mutex_lock and unlock

i have two threads, they run pretty fast, i'm using pthread_mutex_lock and pthread_mutex_unlock to access global (externed variables) data

the problem is that my application takes about 15-20% of CPU running on Ubuntu Linux,

the same code but with EnterCriticalSection and LeaveCritical开发者_JAVA技巧Section and running on Windows uses 1-2% of CPU

That might be a good thing actually - less time spent in wait, more time crunching data.

CPU percentage calculations are very different on different OS-es. Try measuring your throughput - how many "work items" you are able to process in a unit of time.

One possible path for reducing lock contention (if this is indeed your problem) is to connect producer and consumer threads with a queue. Linking new item onto the queue tail is quick, same for un-linking off the queue head, - couple of pointer operations. STL even has a bunch of containers you can use (std::deque, std::queue, std::list). You would have to provide your own locking though. Or look into Intel Threading Building Blocks.

I can't quite tell what your question is, but let's say it's "How do I make the Linux version faster?".

First, are you sure that on Linux you enabled optimization?

Assuming yes, are both programs doing the same amount of "work"?

If that's the case, then you need to profile - that will show you directly where the CPU cycles are being used and should enable you to optimize your algorithm/code.

"i am testing it with 1000 printf's from 2 threads, the linux program will use more CPU always than the Windows one, the windows program finishes faster... i mean DOUBLE Faster. so its a problem of pthread_mutex_lock/unlock, in the MSDN website it's written that entercriticalsection is faster than mutex."

Your analysis is incorrect. The time taken in the printf calls completely swamps the lock/unlock time.

If you think about, it must be this way. Two concurrent printf calls to the same destination must acquire at least one lock to prevent stomping on the shared destination. So printf must be at least as expensive as a lock acquire/release even ignoring the cost of the output operation.

More important than CPU load is which version does more of real work. It could be that the 1-2% of load translates to less real work done. Measure that instead of the CPU load percentage.

found the fastest way, just use pthread rwlocks!