Wait/notify, await/signal, faster blockingqueue that scales with N threads

Question

Hi,
I have been benchmarking a blockingqueue. It holds 100 items before writers block. It uses not-empty/not-full semaphores. Typical stuff.
I have noticed that with 1 writer and 1 reader threads, using synchronized()+wait/notify is faster than reentrantlock+await/signal.
I tried to find the point (in number of W/R threads) where reentrant lock is better.
For the remainder os the discussion, I must say that I never use 'fair' rentrantlocks: I tested them and they are always slower than synchronized.
So, I always use 'unfair' locks.
The thing is, the tests results are messed up. I mean I would expect a monotonous progression in reentrant lock performance as the number of W/R threads is increasing. But the reality (on a dual core dual opteron) shows strange progressions. Without diving into numbers...
I would like to hear about the experiences of other people relatively to:
-queue implementations and readers semaphore, writers semaphores most efficient patterns.
-scalability observations and implementation choices related to the number of threads to be concurrent.
Of course I have been experimenting with notify()/signal() instead of notifyAll()/signalAll() in order to avoid waking up too many writers/readers that do not stand a chance to perform their enqueue/dequeue without going back to wait()/await() again (in my case, fairness isn't an issue for readers, and for the moment, I accept unfair enqueue from writers). Also, a reader can notify/signal not only a waiting writer but another waiting reader if the queue isn't empty after its own dequeue. I'm about to do the dual notify/signal for writers: not only notify/signal a waiting reader but also another waiting writer if the queue isn't full after its own enqueue.
Of course, this good-intentions implementation ends up notifying/signaling a lot. I'm searching for a new way of thinking, in case I have been blinded by too much obsession on my current implementation...! :-)
Thanks.
PS: for those of you that wonders why I don't use j.u.c array blocking queue, that's because I need:
a) many queues enqueue to be able to notify/signal a single thread (1 thread waiting to read many queues). This implies an externally plugged-in readers (not-empty) semaphore.
b) enqueueMany(array), dequeueMany(int max) ->array

Answer 1

In Java 5 ReentrantLock provides much better performance under contention than built-in sync. Conversely built-in uncontended sync is always much faster. In Java 6 contended built-in sync has pulled back some ground on ReentrantLock. So with only two threads it is not surprising that built-in sync is faster.
So the switch over point depends on the level of contention. This is a function of the number of threads (and CPU's) and what they do while holding the lock and between holding the lock.
For evaluating read/write synchronization you need to have a read operation that is relatively long to dominate the cost the heavier read-lock. You also need sufficient parallelism to allow enough concurrent readers to make overall reader "throughput" significant.
Benchmarks are seldom that useful/insightful unless realistic access patterns and workloads are used.