Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin1!goblin2!goblin.stu.neva.ru!plix.pl!newsfeed1.plix.pl!news.icm.edu.pl!news.onet.pl!.POSTED!not-for-mail From: Michal Kleczek Newsgroups: comp.lang.java.programmer Subject: Re: Why "lock" functionality is introduced for all the objects? Date: Tue, 28 Jun 2011 19:53:42 +0200 Organization: http://onet.pl Lines: 127 Message-ID: References: NNTP-Posting-Host: 77-255-242-115.adsl.inetia.pl Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: news.onet.pl 1309283623 21910 77.255.242.115 (28 Jun 2011 17:53:43 GMT) X-Complaints-To: niusy@onet.pl NNTP-Posting-Date: Tue, 28 Jun 2011 17:53:43 +0000 (UTC) User-Agent: KNode/4.4.10 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5738 Lew wrote: > On 06/28/2011 12:41 PM, Michal Kleczek wrote: >> Lew wrote: >> >>> Alex J wrote: >>>> I'm curious why Java designers once decided to allow every object to >>>> be lockable (i.e. [sic] allow using lock on those). >>> >>> Because that makes it possible to do concurrent programming >>> intrinsically. >>> >> >> Could you elaborate more on that? >> Do you mean there is no other way to do it? > > No, I don't mean that, and I don't see how it follows from what I said. > > To elaborate, building monitors into 'Object' (and perforce its > descendants) means that multi-threaded programming is intrinsic, that is, > built in to the > very nature of objects in Java. This makes the simple case for > synchronization, well, simple. You create an object of arbitrary type and > you > can use it as a lock (strictly speaking, a Hoare monitor). This means > that any class can achieve a measure of thread safety by the proper use of > 'synchronized (this)' or the implicit equivalents. The idiom is pervasive > and > extremely useful in Java. It is arguably one of the key aspects to Java's > success as a language. > The point is - I don't see a need to be able to use _every_ object as a monitor. But I have to pay the price (memory usage) of this possibility. >> I find this question quite intriguing as well since it looks quite >> useless for example to be able to lock on java.lang.Integer instance (and >> it is > > So don't lock on an Integer instance, then. > >> strange for me that java.lang.Integer instance occupies much more memory >> as > > "strange"? Based on what? > > 'int' is a primitive, available for convenience because primitives are so > useful without the overhead of objectness. That might not be an optimal > decision, although many successful languages have made the same choice. > (C, > C++, C#, Java.) Given the long history of languages with the same > dichotomy, I find it strange that you find it strange. > "Strange" is a wrong word - it simply is a PITA :) For example it makes it unfeasible to use java.util collections in numerical algorithms. C++ and C# have their own way of dealing with this - templates and generics without erasure. >> int). Surely a compromise must have been done taking into account various >> language features ("synchronized" keyword, lack of multiple inheritance, >> lack of closures) - but I am not that knowlegeable enough to explain this >> compromise in detail. > > Java's supposed "lack" of closures, given the admittedly more verbose > alternatives that actually do exist, poses little if any problem. > Java > does allow multiple inheritance of contract, just not of implementation, If Java had multiple implementation inheritance and closures there would be no need for "synchronized" keyword at all (the modifier could be added as a syntactic sugar). class Foo extends public Bar, private Monitor { void method() { //synchronized is defined in Monitor class synchronized({ //do stuff }); } } > and > actually that distinction makes for clean, elegant code. The > 'synchronized' keyword depends for its utility on the very feature in > dispute in this thread, > namely the presence of a monitor in every object. Far from being a > compromise, this is a key strength of the Java language. > Yet in the end the community seems to agree not to use "synchronized" directly but rather use classes from java.util.concurrent (namely Lock and Condition). So is this keyword really that important? [snip] >>>> The current approach seems to be very simple, but is the performance >>>> penalty so small for not be taken into an account? >>> >>> Yes. Nonexistent, really. >>> >> >> I wouldn't say so - see: >> http://wikis.sun.com/display/HotSpotInternals/CompressedOops >> Especially the sentence: >> "Memory is pretty cheap, but these days bandwidth and cache is in short >> supply" > > Show me the numbers. What penalty? It is (almost) twice as much memory as it could be and twice as much GC cycles. Almost because in real world the number of objects that you need to synchronize on is way lower than the number of all objects you create. > Compared to what instead? If you > give up a feature, you have to add it some other way - what would be the > inefficiency of Java's approach compared to the alternative? > That is actually something I would like to hear as well and - as I read it - what OP asked for - the discussion of pros and cons of different approaches with some explanation of why it is done like this in Java. And your answer looks like "that's the way it is and it is the best way it can be done". -- Michal