tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Price <epr...@ptc.com>
Subject Re: about singletons (ot)
Date Tue, 11 Feb 2003 16:46:56 GMT
Hey Mike,

Thanks for explaining this.  Your examples make it very clear.  When I 
am done with "Effective Java" I plan to pick up one of the threads books 
(both seem to be equally well-recommended).  I understand the basic 
"idea" of threads, but it's tips like this (using synchronized blocks 
instead of synchronizing the entire method, for performance) that I 
don't know much about.


Erik




Mike Jackson wrote:
> Hmm, I wish I'd been paying attention to the list, but basically yes.  You
> get finer control by using synchronized code blocks.  Really the major
> reason is that you in most cases don't really need to synchronize the entire
> method, only small portions of the code.  For example:
> 
> 	protected static Object lock = new Object();
> 	protected static int nextId = 1;
> 
> 	public int getNextId() {
> 		int id = -1;
> 		synchronized( lock ) {
> 			id = nextId;
> 			nextId++;
> 		}
> 		return id;
> 	}
> 
> 	public void setNextId( int i ) {
> 		synchronized( lock ) {
> 			nextId = i;
> 		}
> 	}
> 
> As you can see we've got protection for the variable we care about, namely
> "nextId".  And we've got it setup such that you can have threads accessing
> nextId both in the
> getNext and setNext methods.  Now you're probably saying that you could use
> the synchronized statement on the methods here.  The answer to that is nope,
> when you synchronize the method you're synchronizing on "this", since the
> goal is to protect a static variable you're not going to want to do that.
> 
> Now even if the nextId wasn't static, you have to consider that you might be
> doing other work in the methods.  Work that doesn't need to be synchronized.
> For example we might have something like this:
> 
> 	protected int id = 1;
> 
> 	public synchronized void spin( int i )
> 		/* start crit section */
> 		int i, max = id;
> 		id++;
> 		/* end crit section */
> 		for ( int i = 0; i < max; i++ ) {
> 			;
> 		}
> 	}
> 
> Ok, so this code is safe, but is it efficent?  We're blocking threads from
> entering which will protect the "id" variable, but we'll be taking time
> outside the crit section which will also be protected.  Clearly we don't
> really want to do this.  A better way to do this is:
> 
> 	protected Object lock = new Object();
> 	protected int id = 1;
> 
> 	public synchronized void spin( int i )
> 		int i, max;
> 		/* start crit section */
> 		synchronized( lock ) {
> 			max = id;
> 			id++;
> 		}
> 		/* end crit section */
> 		for ( int i = 0; i < max; i++ ) {
> 			;
> 		}
> 	}
> 
> We're still protecting the crit section, but we aren't impeding other
> threads from entering and even completing their pass through the method
> prior to our finish.
> 
> However sucky examples and all making code thread safe is a lot of work.
> There's some "recipes" out there for generating thread safe code, but quite
> frankly I don't remember them any more.  But there's some really good books
> that we mentioned by other people, the addison westley book is good, and the
> o'reilly threads book is good.
> 
> --mikej
> -=-----
> mike jackson
> mjackson@cdi-hq.com
> 
> 
>>-----Original Message-----
>>From: Erik Price [mailto:eprice@ptc.com]
>>Sent: Wednesday, January 29, 2003 12:26 PM
>>To: Tomcat Users List
>>Subject: Re: about singletons (ot)
>>
>>
>>So you mean that the original author (mike jackson) was saying that he
>>used synchronized code blocks to apply a finer level of detail in
>>specifying what is synchronized and what isn't, as opposed to just
>>declaring an entire method synchronized?
>>
>>I understand that synchronization implies a performance penalty, but I
>>wasn't sure what the advantage to using synchronized blocks over
>>synchronized methods was.
>>
>>
>>Erik
>>
>>
>>
>>
>>Tobias Dittrich wrote:
>>
>>>The reason why you don't want to use synchronized methods is that a
>>>synchronized block can only be executed by one thread at a
>>
>>time. Every other
>>
>>>thread wanting to access this method will be blocked during
>>
>>this time (well,
>>
>>>basically). So you want to try to keep the synchonized blocks
>>
>>as small as
>>
>>>possible.
>>>
>>>Having said that I wonder weather performance is an issue in
>>
>>the singleton
>>
>>>vs only-static discussion. Is there a significant difference in
>>
>>execution
>>
>>>speed? After all one has to make one additional method call
>>
>>every time when
>>
>>>accessing a singleton method (the getInstance() which is  synchronized,
>>>too). And since we're off topic anyway: is a call to a static
>>
>>method faster
>>
>>>than a "normal" one to an object (well, I mean the overhead
>>
>>from the method
>>
>>>call, not the execution speed of the method body ... )?
>>>
>>>
>>>Cheers
>>>Tobi
>>>
>>>
>>>
>>>From: "Erik Price" <eprice@ptc.com>
>>>To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
>>>Sent: Wednesday, January 29, 2003 1:46 PM
>>>Subject: Re: about singletons (ot)
>>>
>>>
>>>
>>>
>>>>Mike Jackson wrote:
>>>>
>>>>
>>>>>The difference is that if you use a singleton there's one instance.  If
>>>>>everything
>>>>>is static then you only have one copy.  Usually when you use a
>>
>>singleton
>>
>>>>>it's to
>>>>>control access to some resource, the intent is that you use the
>>>
>>>singleton
>>>
>>>
>>>>>and some
>>>>>synchronized calls (note I don't mean synchronized methods, but
>>>
>>>synchronized
>>>
>>>
>>>>>code
>>>>>blocks) to control threads using that resource.
>>>>
>>>>Why could you not use synchronized methods?
>>>>
>>>>
>>>>
>>>>Erik
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message