• 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

Is this "thread-safe"?

 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


As I understand it my code is thread-safe in the sense that a single instance of UIDFactory will not create duplicate IDs nor will the static methods create duplicate IDs. I don't care if different instances of UIDFactory can create duplicate IDs nor do I care if an instance might duplicate an ID generated by the static methods, they're intended to be seperate. Using a method that's not synchronized is still okay since it calls a method that is synchronized to generate the actual ID isn't it? Can someone validate my understanding here? Thanks.
[ October 12, 2005: Message edited by: Ken Blair ]
 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ken Blair:
Using a method that's not synchronized is still okay since it calls a method that is synchronized to generate the actual ID isn't it?



That' how I understand this too --- in particular since the unsynchronized method does not otherwise mess with the instance variables.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I noticed a flaw in it today. At the time I didn't realize what exactly a synchronized keyword did with methods. I've since changed the static methods to use synchronized blocks on TIMEMS and ORDINAL to lock those and removed the keyword from the method entierely. Having a synchronized static method locks the entire Class which was undesirable as there's no reason for getUIDAsString() to prevent getNextUID()/getNextUIDAsString which are instance methods and use different variables. Unfortunately I had to give up lazy instantiation to do it, but that was more important. It now looks more like this:



This is the proper way to do it right? I need to lock TIMEMS and ORDINAL to make sure they don't get manipulated by two threads at the same time.
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It was better before. You cant synchronize on an int anyway so that won't compile. A synchronized method only stops entry into other synchronized methods that use the same monitor; it does not effect entry into unsynchronized methods. It also does not stop entry into other synchronized methods that synchronize on a different monitor.

If by chance you are using java 1.5 and that did compile, then we have a new type of mistake to be aleart of in 1.5. autoboxing allowing you to synchronize. without knowing 1.5 i can still safely say never synchronize on an autoboxed variable.

if it were my i would do the following



in other words, there was no flaw. Note: You don't lock objects. You use objects (by using its monitor) to lock blocks of code.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mr. C Lamont Gilbert:
You cant synchronize on an int anyway so that won't compile.



I changed int to Integer. I figured anyone reading would assume that, sorry for the confusion. Would there be anything wrong with using an Integer?

Originally posted by Mr. C Lamont Gilbert:
It was better before. A synchronized method only stops entry into other synchronized methods that use the same monitor; it does not effect entry into unsynchronized methods. It also does not stop entry into other synchronized methods that synchronize on a different monitor.



I disagree with your statement that it's better. I don't dispute anything else in that paragraph, but I also don't see the point. It doesn't stop unsychronized methods, but the only unsynchronized method of relevence calls a synchronized method to do the work.

Does a synchronized static method not lock the monitor on the entire Class? As far as I'm aware, a synchronized static method will block all synchronized methods of the same Class including both static and normal instance methods. That means if a thread called getUID() or getUIDAsString() no other methods could be called (or at least not return) until it was finished. Yes, getUID() and getNextUID() could be called but they couldn't ever return until the lock was given up since they depend on the synchronized methods getUIDAsString() and getNextAsString().

Originally posted by Mr. C Lamont Gilbert:



This introduces a new concept to me of using the monitor of an Object we don't really care about to restrict access to critical sections. That being said, it seems silly in this case. I can just use TIMEMS instead. Why not? You only lose lazy instantiation which is no gain to begin with since you're having to create the other Object. Wouldn't this be optimal:



You made me realize I don't need a lock on ORDINAL because all the code that accesses ORDINAL and TIMEMS will logically need a lock on TIMEMS. I just have to be sure that in the future developers know to never make those accessible to the public and to always lock on TIMEMS if they add in methods that modify ORDINAL or TIMEMS. Am I wrong?
[ October 14, 2005: Message edited by: Ken Blair ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic