If you're a C/C++ programmer who has more recently moved into Java, you may welcome a new section of the Javamex site loosely entitled What is the Java equivalent of...?
The section aims to examine Java equivalents of some of those awkward little features of C/C++ that people tend to miss or not know how to achieve when they migrate to Java. For example:
What is the Java equivalent of unsigned? In C/C++, you can tell the compiler to treat an integer variable as unsigned by adding the unsigned modifier to its declaration. In Java, integer primitives are generally unsigned. But as we see, bitwise operations generally only require the right shift operator to be modified (so that Java uses >>> where C/C++ uses >> to operate on unsigned values). And for arithmetic operations, judicious use of the AND operator can often get us round the problem.
What is the Java equivalent of const? In C/C++, this operator tells the compiler not to allow the variable in question (or the value it points to) to be modified. We discuss the nearest Java equivalents, which actually depend on the circumstances.
The section on memory management in Java vs C/C++ looks at equivalents of operators such as new and malloc(), and their opposites. We see that in general, C/C++ puts more burden on the programmer to deal with memory management issues. Possible C/C++ bugs relating to memory management include allocating memory on the stack and then letting it "escape" the function; such bugs are not possible in Java. But there are issues that do crop up in Java that we sometimes need to be aware of, such as how garbage collection object finalization works, or how to deal with a "raw" block of memory (one typical use of malloc() in C/C++).
If you have a suggestion for a new topic in the Java equivalents section, please leave an appropriate comment on this blog. Corrections or suggestions for the existing articles are always welcome too!
2 comments:
hi,don't really know where else i could write this, so here it is. In reference to this article, you write:
Bad news: because there's no way to completely lock a ConcurrentHashMap, there's no easy option for taking a "snapshot" of the map as a truly atomic operation.
However, there's nothing stopping you from synchronizing on the ConcurrentHashMap for the entire iteration, just as you would do with an old-school Collections.synchronizedMap(...) :
ConcurrentMap<String,Integer> queryCounts =
new ConcurrentHashMap<String,Integer>(1000);
synchronized (queryCounts) {
// do iteration
}
What am I missing?
Great site, keep up the excellent work!
Remember that when you synchronize on an object, you're effectively saying "if another thread is already synchronized on this same object, wait until it releases the lock (comes out of the synchronized block/method)".
In other words, thread-safety relies on ALL accesses to the object in question "playing ball" and also synchronizing.
For a plain HashMap encapsulated with Collections.synchronizedMap(), synchronizing works because other methods such as put() also synchronize on the hash map object. But with ConcurrentHashMap, the point is that the various methods such as put() DON'T synchronize on the ConcurrentHashMap object. So the fact that YOUR thread is synchronizing on the map doesn't stop other methods such as put() from 'sneaking in', because those other methods don't synchronize.
Post a Comment