I understand that use of busy-wait is not a good programming practice and preferably synchronized object (wait-notify) should be used whenever possible. But I would like to
Busy Wait is Faster than normal wait notify.
But Why you wait? because one producer or other thread will do some work and then set a condition(or notify) so that you can actually come out of the busy/wait loop. Now suppose if your Producer is doing some heavy duty task then you actually eats its cpu cycles by doing busy wait (mainly true in single processor system), Which will in turn may make your system overall slow.
So now when you should use busy wait. As Claudio says its mainly used in low latency system. But still its not be used blindly. Use busy wait when your producer is producing around a steady rate. If your producer produces items at variable rate (normally demonstrated by Poisson Distribution) then you should probably use wait notify.
Normally the best tradeoff in high Throughput and Low latency systems is to go with do a busy wait for some time and then go to the wait(). If your system requires Ultra Lowlatency then you may go with many optimizations one of which could be Busy-Wait. But it should not be that every thread is doing busy-wait. Make sure only some Consumers may be around N/2 Consumers are doing busy wait where is N is the number of cores in your System. Wasting CPU cycles may effect overall performance and responsiveness of your system. For your ref: Even Normal ReentrantLock and its variants apply these strategies. i,e i.e when a thread calls lock.lock() its tries to acquire lock two times before qoing into the queue and wait for lock to be released. For Low Latency Systems you can even define your own lock for specific scenarios where they try for more 10 times before going into the queue (they will be variant of so called spin locks)