4 ms·

That doesn't really explain it though, IMO. IIUC, it's a sequence of instructions that either runs to completion atomically or doesn't. If it is interrupte

That doesn't really explain it though, IMO. IIUC, it's a sequence of instructions that either runs to completion atomically or doesn't. If it is interrupted by anything the kernel jumps you to the abort/retry vector you set with a guarantee that the last instruction in the sequence was not executed. (Based on my reading of the LWN article rwmj posted).

khuey 5mo ago
Yes, the API contract isn't "don't interrupt me during this critical section" it's "if you have to interrupt me during this critical section, go to this recovery/restart code". There is a time-slice extension feature in the works that's roughly "please let me finish this critical section before you interrupt me". But a hard guarantee that userspace code won't be interrupted is probably untenable in a preemptive multitasking system.
- leoc 5mo ago
  Something not completely dissimilar to https://en.wikipedia.org/wiki/PCLSRing https://en.wikipedia.org/wiki/PCLSRing then?
- torginus 5mo ago
  > But a hard guarantee that userspace code won't be interrupted is probably untenable in a preemptive multitasking system. I wonder why this is the case. Considering modern (personal) computers have more cores than available work (or won't starve other processes even if they hog a part of the available cores), I would not think it so horrible for an OS to offer a guarantee to some (maybe specially privileged) processes, that as long as they don't wait on a resource, they won't be interrupted. We also have a perfectly workable model for describing such a state to the OS - priority inversion. Imagine a 'god mutex', which when acquired would boost your thread's priority to the maximum - as if the 'god process' would be waiting for said mutex and as long as your thread held it, it couldn't continue working, until your thread finished using it. I think it would be a neat feature for certain real-time(ish) scenarios, like audio/video processing. I think a lot of modern OS facilities are catering towards a world with much scarcer resources than our current one, for example, it would be perfectly fine for a process to assume at least a core part of its data is always in RAM and can't be swapped out. When you get into low-level systems, like kernels, a lot of the need for special privileges comes from having to have these guarantees, which could be granted nowadays on a much more lenient basies.
  - saagarjha 5mo ago
    Because poorly behaved processes can use this to lock up the machine.
crote 5mo ago
> it's a sequence of instructions that either runs to completion atomically or doesn't The way I read it, it either runs to completion in one go, or gets restarted from the beginning. This means the sequence as a whole isn't executed atomically, as the already-executed instructions during an interrupt aren't rolled back. It can be used to build atomic actions, but it is up to the developer to create a sequence of instructions where the very last instruction "commits" the entire operation, with the side-effects of partial execution being harmless.
- bryanlarsen 5mo ago
  Yes, it's either atomic or the last instruction is guaranteed not to have run. I made this a little harder to read by inserting another clause in the sentence.
  - zestyping 5mo ago
    [dead]

khuey 5mo ago

Yes, the API contract isn't "don't interrupt me during this critical section" it's "if you have to interrupt me during this critical section, go to this recovery/restart code". There is a time-slice extension feature in the works that's roughly "please let me finish this critical section before you interrupt me". But a hard guarantee that userspace code won't be interrupted is probably untenable in a preemptive multitasking system.

leoc 5mo ago
Something not completely dissimilar to https://en.wikipedia.org/wiki/PCLSRing https://en.wikipedia.org/wiki/PCLSRing then?
torginus 5mo ago
> But a hard guarantee that userspace code won't be interrupted is probably untenable in a preemptive multitasking system. I wonder why this is the case. Considering modern (personal) computers have more cores than available work (or won't starve other processes even if they hog a part of the available cores), I would not think it so horrible for an OS to offer a guarantee to some (maybe specially privileged) processes, that as long as they don't wait on a resource, they won't be interrupted. We also have a perfectly workable model for describing such a state to the OS - priority inversion. Imagine a 'god mutex', which when acquired would boost your thread's priority to the maximum - as if the 'god process' would be waiting for said mutex and as long as your thread held it, it couldn't continue working, until your thread finished using it. I think it would be a neat feature for certain real-time(ish) scenarios, like audio/video processing. I think a lot of modern OS facilities are catering towards a world with much scarcer resources than our current one, for example, it would be perfectly fine for a process to assume at least a core part of its data is always in RAM and can't be swapped out. When you get into low-level systems, like kernels, a lot of the need for special privileges comes from having to have these guarantees, which could be granted nowadays on a much more lenient basies.
- saagarjha 5mo ago
  Because poorly behaved processes can use this to lock up the machine.

crote 5mo ago

> it's a sequence of instructions that either runs to completion atomically or doesn't The way I read it, it either runs to completion in one go, or gets restarted from the beginning. This means the sequence as a whole isn't executed atomically, as the already-executed instructions during an interrupt aren't rolled back. It can be used to build atomic actions, but it is up to the developer to create a sequence of instructions where the very last instruction "commits" the entire operation, with the side-effects of partial execution being harmless.

bryanlarsen 5mo ago
Yes, it's either atomic or the last instruction is guaranteed not to have run. I made this a little harder to read by inserting another clause in the sentence.
- zestyping 5mo ago
  [dead]