Stupid example.  Should have been an array...
----- Original Message -----
From: "William Kaufman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 12, 2001 3:47 PM
Subject: RE: Java Question


> > public static String getYear(String str){
> >     synchronized(str){
> >       newStr = str.substring(0,4);
> >       return newStr;
> >     }
> >   }
>
> While your use of "synchronize" is correct, _this_ synchronization is not
> necessary at all.  java.lang.String is unmodifiable: there's nothing you
can
> do with it that might conflict with what another thread will do with it.
> So, you never have to worry about conflicts, and you never need to
> synchronize.
>
> The answer is,
>
> 1) You need to synchronize when two threads running code might modify the
> same data at the same time.
>
> 2) You need to synchronize on the exact same object around all code which
> modifies a given bit of data.
>
> 3) Never synchronize on java.lang.Class objects.
>
> The only issue about static/non-static in there is that synchronizing a
> static method effectively synchronizes on the object's Class, which is a
> no-no.
>
> (You might want to read up on concurrency--see Doug Lea's "Concurrent
> Programming", or his web site, http://g.oswego.edu/ .)
>                                         -- Bill K.
>
>
> -----Original Message-----
> From: Brandon Cruz [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 12, 2001 11:56 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Java Question
>
>
> So would changing something simple from...
>
> public static String getYear(String str){
>       newStr = str.substring(0,4);
>       return newStr;
>     }
>
> to...
>
> public static String getYear(String str){
>     synchronized(str){
>       newStr = str.substring(0,4);
>       return newStr;
>     }
>   }
>
> be correct if I want to avoid having incorrect results returned when
> accessed by multiple threads?  It compiles like that, but is that all that
> is needed to synchronize something?
>
> Brandon
>
> -----Original Message-----
> From: Luba Powell [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 12, 2001 1:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Java Question
>
>
> Actually the outcome is predictable:
> monitorenter will obtain objectref on this (aload_0)
> * if no other thread has locked the object
> * if the object is currently locked by another thread (monitorenter
> instruction)
> * if the current thread already owns a lock - the lock is released when
the
> counter
>     returns to 0
>
>
> .method static doSort([I)V
>     aload_0
>     monitorenter
>     ; sensitive code
>     monitorexit
>     ...
>     return
> end method
>
> ----- Original Message -----
> From: "Brandon Cruz" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 12, 2001 2:18 PM
> Subject: Java Question
>
> ----- Original Message -----
> From: "Pae Choi" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, June 12, 2001 2:41 PM
> Subject: Re: Java Question
>
>
> > When you access the 'synchronized' static method, it locks its class.
> > so this will ensure the thread-safe access. Otherwise, the result is
> > unknown.
> >
> >
> > Pae
> >
> >
> > > I have looked all over and can't find the answer to this simple
> question.
> > > If you use a static method, do you have to synchronize it in case
other
> > > people may access it at the same time.  For example, I have a static
> Utility
> > > class to do date calculations.  The method Utility.getMonth(String
date)
> > > takes in a full date string, parses it, and returns just the month
> value.
> > > If 5 different people all using the website attempt to use
> > > Utility.getMonth(String date) at the same time for different dates,
will
> it
> > > return the right results?  If not, do I have to synchronize it or
> something
> > > in case multiple users attempt to access it?
> > >
> > > I know this is not really related to tomcat, but since I am using
> tomcat,
> > > and everyone else using tomcat is also a java developer, I figured
this
> is
> > > the best place I can ask.
> > >
> > > Thanks for any help!!!
> > >
> > > Brandon
> > >
> >
>

Reply via email to