Does using a lock has better performance than using a local (single application) semaphore ?

Question

Does using a lock has better performance than using a local (single application) semaphore?

I read this blog from msdn : Producer consumer solution on msdn

and i didn't like their solution to the problem because there are always 20 elements left in the queue.

So instead, i thought about using a Semaphore that will be available only in my app (i just won't name it in the constructor), but i don't know how it will effect the app's performance.

Any one has an idea if it'll hurt the performance? what are the other considerations to use lock and not Semaphore?

tnx!

Answer 1

Lock(obj) is the same as Monitor.Enter(obj); A lock is basicaly an unary semaphore. If you have a number of instances of the same ressource (N) you use a semaphore with the initialization value N. A lock is mainly used to ensure that a code section is not executed by two threads at the same time.

So a lock can be implemented using a semaphore with initialization value of 1. I guess that Monitor.Enter is more performant here but I have no real information about that. A test will be of help here. Here is a SO thread that handels about performance.

For your problem a blocking queue would be the solution. (producer consumer) I suggest this very good SO thread.

Here is another good source of information about Reusable Parallel Data Structures.

Answer 2

The solution in the MSDN article has a bug where you'll miss an event if SetEvent is called twice by the producer in quick succession whilst the consumer is processing the last item it retrieves from the queue.

Have a look at this article for a different implementation using Monitor instead:

http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!672.entry

Answer 3

In general: If your consumer thread manages to process each data item quickly enough, then the kernel-mode transition will incur a (possibly significant) bit of overhead. In that case a user-mode wrapper which spins for a while before waiting on the semaphore will avoid some of that overhead.

A monitor (with mutual exclusion + condition variable) may or may not implement spinning. That MSDN article's implementation didn't, so in this case there's no real difference in performance. Anyway, you're still going to have to lock in order to dequeue items, unless you're using a lock-free queue.