• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Question regarding Synchronized(anObject)

 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
Would someone confirm that this block of code doesn't really serve any purpose?

I'm of the opinion that creating the Object 'sync' and then synchronising on it is pointless since the object is local to the method.
From what I've learnt (from doing the JSCD) the Object 'sync' needs to be a class member. FYI There's only one instance of this class, the class is acting as a connection pool. Ignore the 'wait(100)' I'll replace that with a wait() and add a notify where it's required.
Of course I may have lost the plot completely in which case can someone tell me why the code is perfectly fine.
Thanks in advance for any response
[ August 11, 2003: Message edited by: Jim Yingst ]
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It seems pretty weird, but you never know -- sometimes dumb looking code turns out to be smart...
One thing is for certain: the wait() will always last for 100 milliseconds, unless another thread calls interrupt(); no-one will ever call notify().
Perhaps that's the point. The author of this code seems to be using wait(100) as a substitute for Thread.sleep(100), maybe not realizing that interrupt() will interupt sleep() just as it interrupts wait().
On the other hand, the synchronized block also serves as a memory barrier, and so maybe they have a vague idea about propagating memory contents across threads, and are trying to kill two birds with one stone? In that case, it's the opposite of "programming by intention," it's "try something and see what happens."
Anyway, I think I'd replace the whole synchronized block with a call to Thread.sleep(100), which expresses the intent much more clearly.
[ August 11, 2003: Message edited by: Ernest Friedman-Hill ]
 
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
100 seconds -> milliseconds
Yup. A simple call to Thread.sleep() would be much more straightfoward
 
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll bet that the original programmer did not know about Thread.sleep(). The synchronized block is there because it's required by wait().
I've seen worse substitutes for Thread.sleep():
for (int i=0;i<100000;i++);
AAAAAAAAAAAHHHHHHHHHHHHHHH.
 
I am a man of mystery. Mostly because of this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic