Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

synchronized != atomic

 
Gytis Jakutonis
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • 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.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • 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
  • 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
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • 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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic