1

I'm learning about critical section of multithreading. I have a general statement:

In a single CPU system, disable interrupt is a solution of race condition.

But I also learn from another site that

Threads generally don't interrupt each other.

So how can disable interrupt prevents race condition? Can this possible be explained in terms of Linux?

closed as unclear what you're asking by Stephen Harris, msp9011, RalfFriedl, sam, Romeo Ninov Dec 28 '18 at 6:50

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

2

The first statement is true, but it is meaningless on Linux or on any systems. It is because most drivers or hardware handling is done by interrupts and it is impossible do it differently. For example, if a packet arrives from the network, the CPU will know it by an interrupt initiated by the network card.

But these interrupts are invisible for the user space processes, and it doesn't affect them.

Except rare, typically embedded scenarios, no Linux work without interrupt handling.

What can cause race condition, is the context switching, i.e. if the kernel gets away the CPU from a process and gives it to another one. It happens typically by an interrupt from the timer. If only a single process runs, or if the whole scheduler is somehow turned off (maybe it is possible in some embedded environment, but very atypical), then this doesn't happen, and you have a single-process system a'la DOS. It is true, that there is no possibility of a race condition because there is no multitasking.

In a multi-CPU system, if multiple CPUs are concurrently active, there is also the possibility for a race condition, because multiple threads can run concurrently even if there is no scheduler active. Note, also this scenario is very alien to Linux (or to any not embedded OS).


The second sentence, "threads are not interrupting each other" is mainly true. Threads are essentially processes, using the same address space. Multiple threads typically don't interrupt each other. Maybe they could send signals to each other, but that is all. This statement is independent from the previous one.

  • For the first statement I think my book really means "a process can disable interrupt during changing the shared variable", not infinitely disable it. (Since I've tired for being specific, sorry for unclear question.) – ptr_user7813604 Dec 26 '18 at 20:42
  • 1
    @ptr_user7813604 Thanks :-) The real problem of the race conditions happen on Linux, if multiple threads - seeing the same adress space, thus operating on the same data structures - are manipulating the same data structure concurrently. But it is practically independent from the interrupts, it is the thread synchronization problem. The general solution is to use barriers or locks to avoid the concurrent operation on the same data structure. – peterh Dec 26 '18 at 21:03
  • 1
    @ptr_user7813604 This sentence: "a process can disable interrupt during changing the shared variable" is probably for kernel threads or for embedded systems. User processes can't disable interrupts on Linux, even if they somehow do it, the likely result will be a hangup of the machine. Kernel drivers can do that, but it is highly un-suggested even for them. User processes typically don't deal with interrupts, they see a much more virtualized environment. For example, they deal with sockets, and it is the task of the kernel to translate their socket operating primitives to hardware calls. – peterh Dec 26 '18 at 21:07
  • 1
    @ptr_user7813604 Thus, the user process handles a network socket. How it converts to interrupts and DMA transfers with the network card, is already the task of the kernel. If you download a website with a firefox, the firefox handles network sockets and no interrupts. However, race problem can happen: imagine if multiple tabs are downloading static images, and they want to store it in the browser cache. Then the firefox developers need to solve the problem that the data structures of the browser cache might be corrupted if they aren't handled enouggh wisely. – peterh Dec 26 '18 at 21:11
  • 1
    @ptr_user7813604 Yes. If the context switching happens while both threads are in the same critical section, a data corruption is quite possible. – peterh Dec 26 '18 at 21:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.