Example for Q3:
class List { private final ArrayList<String> list = new ArrayList<String>(); void add(String newValue) { synchronized (list) { list.add(newValue); } } }
vs.
private final ArrayList<String> list = Collections.synchronizedList();
The questions are more from a learning/understanding point of view. Thanks for attention.
Non-blocking concurrency is particularly advantageous when there is a lot of contention. You can't use it when you need blocking (fair-locking, event-driven stuff, queue with maximum length etc.), but if you don't need that, non-blocking concurrency tends to perform better in most conditions.
A process that is blocked is one that is waiting for some event, such as a resource becoming available or the completion of an I/O operation. In a multitasking computer system, individual tasks, or threads of execution, must share the resources of the system.
In a blocking thread model, when the program carries out a blocking action such as IO, the OS level thread also blocks. In contrast, a non-blocking system does not block an OS thread when the thread needs to block on a blocking operation (e.g. I/O) rather it frees up the OS thread.
Unlike a LinkedBlockingQueue, a ConcurrentLinkedQueue is a non-blocking queue. Thus, it does not block a thread once the queue is empty. Instead, it returns null. Since its unbounded, it'll throw a java.
What is Non-blocking Concurrency and how is it different.
Formal:
In computer science, non-blocking synchronization ensures that threads competing for a shared resource do not have their execution indefinitely postponed by mutual exclusion. A non-blocking algorithm is lock-free if there is guaranteed system-wide progress; wait-free if there is also guaranteed per-thread progress. (wikipedia)
Informal: One of the most advantageous feature of non-blocking vs. blocking is that, threads does not have to be suspended/waken up by the OS. Such overhead can amount to 1ms to a few 10ms, so removing this can be a big performance gain. In java, it also means that you can choose to use non-fair locking, which can have much more system throughput than fair-locking.
I have heard that this is available in Java. Are there any particular scenarios we should use this feature
Yes, from Java5. In fact, in Java you should basically try to meet your needs with java.util.concurrent as much as possible (which happen to use non-blocking concurrency a lot, but you don't have to explicitly worry in most cases). Only if you have no other option, you should use synchronized wrappers (.synchronizedList() etc.) or manual synchronize
keyword. That way, you end up most of the time with more maintainable, better performing apps.
Non-blocking concurrency is particularly advantageous when there is a lot of contention. You can't use it when you need blocking (fair-locking, event-driven stuff, queue with maximum length etc.), but if you don't need that, non-blocking concurrency tends to perform better in most conditions.
Is there a difference/advantage of using one of these methods for a collection. What are the trade offs
Both have the same behavior (the byte code should be equal). But I suggest to use Collections.synchronized
because it's shorter = smaller room to screw up!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With