• 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:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

Is this small piece of code thread-safe?

 
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, this TimingMonitoris a class that can count the execution time of codes:

i was trying to use it in this way:






and this is the source of the class

 
author
Posts: 50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It won't crash (thanks to the synchronized map) but it won't work right either. Think about what happens with the following sequence:

Thread A calls TimingMonitor.start("load file")
Thread B calls TimingMonitor.start("load file")
Thread A TimingMonitor.stop("load file")
Thread B calls TimingMonitor.stop("load file")

Both stop() calls will show the time since thread B called start().

 
Marshal
Posts: 26912
82
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The easiest way to fix that would be to make all of those methods not be static. Then a thread would have to create a TimingMonitor instance and use that to do the timing. As it is you have something which can only time one thread at a time across the whole JVM.

That still wouldn't produce thread-safe code, but if every piece of code which needed to be timed would create its own TimingMonitor instance and avoid sharing it with any other thread, thread safety wouldn't be an issue anyway.
 
Master Rancher
Posts: 4062
56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another approach is to use a ThreadLocal to ensure that every TimingMonitor uses a different thread. This results in easier-to-use code, as clients don't need to create the instance and save it locally - it's just there. The only downside I see is that if you ever want to time something across different threads - i.e. start a timer in one thread and stop it in another - you can't. Normally that's not a problem, but occasionally it might be.

I believe JDK 7 and 8 will enable slicker ways to do this. But of course, they're not here yet, unless you want to use a beta of JDK 7.
 
Chrix Wu
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sergey Babkin wrote:It won't crash (thanks to the synchronized map) but it won't work right either. Think about what happens with the following sequence:

Thread A calls TimingMonitor.start("load file")
Thread B calls TimingMonitor.start("load file")
Thread A TimingMonitor.stop("load file")
Thread B calls TimingMonitor.stop("load file")

Both stop() calls will show the time since thread B called start().



Thanks,

but i think i can add some code to throw exception if users trying to do above.

then this can be avoid.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic