-3

Monitor = mutex(lock) + condition variable

Each Java object has a monitor, holding above principle.

synchronized key word claim a monitor(lock + conditionvar) of an object.

My understanding is, for atomicity, conditionvar is not required, lock(mutex) would suffice.

To maintain atomicity of a memory area, Java provides Lock , atomic package and binary semaphore.

For atomicity, Which approach is better in terms of performance?

overexchange
  • 15,768
  • 30
  • 152
  • 347
  • What do you mean by "condition variable"? Also, "atomicity" of what? Read? Write? Computation? ... – Matthieu Oct 05 '17 at 19:45
  • @Matthieu As [wiki](https://en.wikipedia.org/wiki/Monitor_(synchronization)) says, condition variable is a queue of threads. JVM maintains this queue of wait & entry threads in [ObjectMonitor](http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.hpp), Line 77. When you say `obj.wait()` the thread sits in this queue(`_WaitSet`) owned by `obj`. We use condition variable for [ordering](http://jeremymanson.blogspot.ca/2007/08/atomicity-visibility-and-ordering.html). atomicity of what? atomicity of a memory area, which we call as criticial section. – overexchange Oct 05 '17 at 19:54
  • @Matthieu, https://en.wikipedia.org/wiki/Monitor_(synchronization)#Condition_variables – Solomon Slow Oct 05 '17 at 20:08
  • @jameslarge By any chance, do you know, any reason for downvotes and close vote, for this question? – overexchange Oct 05 '17 at 20:09
  • None of the alternatives that you proposed provides any performance guarantee. The answer to your question could depend on what platform/OS/JVM you are using. It's usually better to worry first about making your code readable and maintainable, and only worry about performance if it proves to be an actual problem. – Solomon Slow Oct 05 '17 at 20:10
  • I didn't downvote, but most likely it's because your question is a little off-topic for this forum. The best questions to ask here go something like, "Here's my code..., Here's what I thought it would do..., Here's what it actually did instead..., can somebody help me understand what happened?" – Solomon Slow Oct 05 '17 at 20:12
  • @jameslarge Are there any other solutions for atomicity provided by java, apart from mentioned in query? – overexchange Oct 05 '17 at 20:13
  • @overexchange none. The [concurrency tutorial](https://docs.oracle.com/javase/tutorial/essential/concurrency/index.html) is all Java has. – Matthieu Oct 05 '17 at 20:24

1 Answers1

0

It depends on the access pattern: synchronized(var) { ... } is the simplest to use as it doesn't require explicit unlock, unlike ReentrantLock. Those two are the same: synchronized(var) will grab a lock on var, while Lock will grab a lock on "itself" (so to say). But the ReentrantLock allows you to get extended information (see its javadoc for more information: isHeldByCurrentThread() and getHoldCount()).

Performance-wise, ReentrantReadWriteLock will improve performance when you have few writes and many reads (as you don't need to lock when you're only reading), but you should take extra care when taking and releasing locks, as "ownable synchronizers" can deadlock your threads (read and write locks are not treated in the same manner).

But if the data you want to read/write is a "simple type" (as described in the atomic package javadoc), you will get the best performance by using the AtomicInteger and the likes, as they use specific, optimized CPU instruction set such as compare-and-swap in SSE* set.

Matthieu
  • 2,736
  • 4
  • 57
  • 87
  • [this](https://stackoverflow.com/q/442564/3317808) has been told in my first part of query. Your first line of answer does not make sense. – overexchange Oct 05 '17 at 20:06
  • @overexchange I rephrased a bit to emphasize that they are the same. – Matthieu Oct 05 '17 at 20:10
  • Yes, `synchronized(var)` will grab a lock on `var`, but `var` also has conditionvar, which is of no use for atomicity – overexchange Oct 05 '17 at 20:12
  • @overexchange you don't have to delete all your comments, it's hard for me to read all your links and then reply to a deleted comment :) The question you linked to is about `synchronized(this)` whereas here I speak of `synchronized()` in general (not only `this`). – Matthieu Oct 05 '17 at 20:14
  • Am thinking to migrate this query to SE, as james says it is off-topic. Would you like to delete this answer? – overexchange Oct 05 '17 at 20:14
  • @overexchange It's a programming question, I think it's good on SO. Who's James? I don't see any close votes for "off topic": so far it's only "too broad"/"unclear"... – Matthieu Oct 05 '17 at 20:19
  • Please read the [comment](https://stackoverflow.com/questions/46593358/atomicity-lock-vs-atomic-vs-binary-semaphore-performance#comment80141078_46593358) from *James large* – overexchange Oct 05 '17 at 20:19
  • @overexchange *`var` also has a conditionvar, which is of no use for atomicity*. It is of the utmost importance for atomicity, as it is the one guaranteeing it. – Matthieu Oct 05 '17 at 20:23
  • Do you understand your comment? I don't understand what it says. Please delete your answer, it has mistakes. – overexchange Oct 06 '17 at 05:48
  • @overexchange if you think it has mistakes, please point to them clearly so I understand them and correct it. Or please delete your question. – Matthieu Oct 06 '17 at 08:03