• 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

synchronized != atomic

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
in many posts I see code or design, which is related to notion that synchronized methods (or blocks) are atomic since only one thread can be active in a synchronized section. IMO such definitionit is a bit inaccurate. I'll skip all considerations regarding code inside synchronized block, which may break atomicy, and take into account only one issue. It is thread interruption. IMO atomic execution can not be broken, while execution of a synchronized block can be interrupted at any time, i.e. synchronized != atomic.
Since synchronized block is not atomic, I'm not sure how to solve the following issue. I'm going to use separate manager class to control free space(i.e. deleted records). Solution was quite simple and clear till I've got that breaked atomicy idea. Suppose we have create() implementation: <get_free_space> <...> <write_record> <...>. And if thread gets interruped after getting free space, that free record is left invalid, while other clients think(by getting information from free space manager) that this record is valid. IMO no synchronization can solve this issue, and that 'great' idea about free space manager goes into deadlock. Seems like this issue (atomicy) can have impact on other implementation parts too.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gytis,
You are right - the common definition of atomic is along the lines of:


(adj.) Not interruptible. An atomic operation is one that always appears to have been executed as a unit.
(See http://www.google.com.au/search?q=define:atomic for more definitions)


And synchronized blocks can fail the first part, although the second part is correct.
But even though code inside a synchronized block can be interrupted by the thread scheduler, no other thread can gain the mutex that the interrupted thread owns.
So if you synchronize on the file pointer for any read or write operation, then even if the read or write operation gets interrupted, no other thread will be able to gain the mutex on the file pointer, so it will not be able to read the partial data.
Regards, Andrew
 
Gytis Jakutonis
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andrew,
so should I place all interruption sensitive code into try-catch block and handle InterruptedException? Should this approach solve my problem? Thanks.
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gytis,
I agree that you should have all code which may be interrupted within try ... catch blocks.
You should then start thinking about what could interrupt your code - is there any code that you have written that may interrupt your method?
If you have not written any such code, then what state is your server in if it gets an interruption? Can you even proceed with transactions now, knowing that some code would have had to be introduced to your server which is creating the interruption? Should your server continue operating in an invalid state? How should you warn the clients about your current state?
Note: I am deliberately only asking questions at this time, rather than providing my solution. You may find that answering these questions may help you to determine what you need to do. And it may help you to formalise a design decision for your design decisions document.
Regards, Andrew
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic