0

For example, I have a method called increase.

public synchronized void increase() {
    count++;
}

Two threads (T_1 and T_2) both execute this method. We know count++ is a compound operation that consists of read, modify and write. If T_1 gets the lock firstly, execute read, can T_1 be interrupted at this point (Although T_2 can't do anything besides waiting for the lock to be released)?

From Concurrency in Go by Katherine Cox-Buday, it says:

When something is considered atomic, or to have the property of atomicity, this means that within the context that it is operating, it is indivisible, or uninterruptible.

I think it means that atomicity is truly uninterruptible.

But from one answer to java - What does "atomic" mean in programming? - Stack Overflow, it says:

"Atomic operation" means an operation that appears to be instantaneous from the perspective of all other threads. You don't need to worry about a partly complete operation when the guarantee applies.

I think it means that atomicity is virtually uninterruptible (it can be interrupted, but from the perspective of all other threads, it seems it can't be interrupted.).

So, which one is right?

Jason Law
  • 965
  • 1
  • 9
  • 21
  • 2
    It could be either, depending on the circumstances, but the second one is the only one that's true no matter what. – Louis Wasserman Dec 19 '19 at 02:02
  • @LouisWasserman So, under which circumstance, it could be truly uninterruptible? under which circumstance, it could be virtually uninterruptible? – Jason Law Dec 19 '19 at 02:11
  • @LouisWasserman you say "the second one is the only one that's true no matter what", do you mean that "from the perspective of all other threads, it seems it can't be interrupted" is always true? – Jason Law Dec 19 '19 at 02:12
  • Yes. For an atomic operation, the second version is always true. – Louis Wasserman Dec 19 '19 at 02:19
  • 1
    Why do you think there is a difference between the two? Or, asked another way: if you cannot observe the interruption, then how do you know the interruption even happened? And if you can't know whether the interruption even happened, then is there even a difference between virtually and truly uninterruptible? – Jörg W Mittag Dec 19 '19 at 07:42
  • *"I think it means that atomicity is virtually uninterruptible (it can be interrupted, but from the perspective of all other threads, it seems it can't be interrupted.)."* ... the vagaries of the thread scheduler are what they are, but with respect to any thread it hardly matters at all. In this way, the term "virtually interruptible" has no semantics that would be useful at all to a software engineer. – scottb Dec 19 '19 at 18:25

1 Answers1

0

A it was pointed out there is now way for your program to understand the difference. But threads scheduler on OS level is free to suspend a thread and resume another thread. For example if inside synchronized method you are doing some blocking I/O (like reading user input or reading from socket) scheduler can detect it and pause a thread which holds lock but is blocked on I/O and try to resume any other thread (maybe even the one which is also waiting for the same lock).

Ivan
  • 8,508
  • 2
  • 19
  • 30