I'm learning about synchronization and now I'm confused about the definition of atomic operation. Through searching, I could only find out that atomic operation is uninterruptible operation.
Then, won't the atomic operation only be valid for uni processor system since for multiprocessor system, many operation can be run simultaneously?
This link explains it pretty much perfectly (emphasis mine):
On multiprocessor systems, ensuring atomicity exists is a little
harder. It is still possible to use a lock (e.g. a spinlock) the same
as on single processor systems, but merely using a single instruction
or disabling interrupts will not guarantee atomic access. You must
also ensure that no other processor or core in the system attempts to
access the data you are working with. The easiest way to achieve this
is to ensure that the instructions you are using assert the 'LOCK'
signal on the bus, which prevents any other processor in the system
from accessing the memory at the same time. On x86 processors, some
instructions automatically lock the bus (e.g. 'XCHG') while others
require you to specify a 'LOCK' prefix to the instruction to achieve
this (e.g. 'CMPXCHG', which you should write as 'LOCK CMPXCHG op1,
op2').
Related
I have read a couple of articles and I am confused about the difference between strict consistency (which is defined as "It can be better understood as though a global clock is present in which every write should be reflected in all processor caches by the end of that clock period.") and atomic consistency (or linearizability, which is defined as "sequential consistency with the real-time constraint"). Both definitions come from Wikipedia. The source of my confusion is the fact that the strict model provides that every process see a change immediately and atomic consistency is also said to work in real-time providing the same sequence of writes for every process.
The requirement for maintaining a system-wide distribution of global clock for a strict consistency case is hopefully clean enough by itself.
The atomic consistency thus needs some more warranties, in exchange to not maintaining the global clock, to still become and stay consistent system-wide.
Here comes useful the warranty from HRT-system, as it keeps the sequential consistency within its realm of deterministic, a-priori known finite time. Thus the state-change propagation planning is possible and holds throughout the whole life-cycle of the HRT-system operation.
On "sequential consistency with the real-time constraint" :
This option ought be understood as a technically less strict, yet for maintaining the system-wide consistency-goal sufficient enough ( see determinism + known deadline below ), not having a need to guarantee a system-wide distribution of a uniform clock.
For touching what the "real-time constraint" actually is useful for, let me borrow ( incl. original typos, accents added ) from a book from Giovanni Di Sirio on Real-Time Operating System (RTOS) disambiguation :
What an RTOS is
An RTOS is an operating system whose internal processes are guaranteed to be compliant with (hard or soft) realtime requirements. The fundamental qualities of an RTOS are:
- Predictable. It is the quality of being predictable in the scheduling behavior.
- Deterministic. It is the quality of being able to consistently produce the same results under the same conditions.
RTOS are often confused with “fast” operating systems. While efficiency is a positive attribute of an RTOS, efficiency alone does not qualifies an OS as RTOS but it could separate a good RTOS from a not so good one.
A deciding factor is the (un-)certainty of completing each work-unit within a(n un-)known deadline :
“A non real time system is a system where the programmed reaction to an event will certainly happen sometime in the future”.
Whereas :
Soft Real Time.A Soft Real Time (SRT) system is a system where not meeting a deadline can have undesirable but not catastrophic effects, a performance degradation for example. Such systems could be described as follow :
“A soft real time system is a system where the programmed reaction to an event is almost always completed within a known finite time”.
Hard Real Time.An Hard Real Time (HRT) system is a system where not meeting a deadline can have catastrophic effects. Hard realtime systems require a much more strict definition and could be described as follow :
“An hard real time system is a system where the programmed reaction to an event is guaranteed to be completed within a known finite time”.
As part of my research I need to provide the reader with a comprehensive introduction to distributed systems. I am currently struggling with properly defining a number of the concepts that are recurring in literature on distributed systems and transactions. These are (a) nodes, (b) processes, (c) transactions and, (d) operations. I could really use some help in understanding their correlation, as I seem to continuously mix up nodes with processes and transaction with operations. Any input is appreciated!
I have already tried to grasp these concepts by researching the following literature:
Distributed Systems: Concepts and Design (G. Coulouris et al.)
A brief introduction to distributed systems (A.S. Tannenbaum)
I'm not sure what type of the ambiguity you exactly perceive in the defined terms and thus it's harder to put the right answer. These terms have the same meaning in the distributed systems terminology as any other part of the information technology science.
To be more concrete.
The node is usually "a machine" which runs one or multiple processes. The process executes operations. Operations may be grouped in a transaction (the transaction is composed from operations).
I just quickly searched in the resources you referred and there is said
A computing element, which we will generally refer to as a node, can
be either a hardware device or a software process.
The node runs processes. But the node itself can be a real hardware (a machine) or it could be a virtual machine - which is a process that runs on some machine (a real hardware).
From distributed system perspective you don't mind what the node is in reality (it's real as the HW or it's virtual as the SW) but it's a "container" for running processes.
Process is "a runtime". It processes something. It can process numbers, data, messages... The chunks of the work that is processed inside of the process are operations. E.g. you save data to a database and you do it as an operation.
The transaction defines a unit of work which consists of several operations. The transaction brings you guarantees over those operations. What are those guarantees depend on model you use. If you think about ACID transactions (as defined in paper Principles of Transaction-Oriented Database Recovery from 1983) then you are guaranteed that the all operation are successfully process or no of them is(A), consistency is maintained(C), parallel transactions do not interfere(I) and you are guaranteed that transaction outcome is persistent(D).
Atomic instructions are those which execute as a whole and cannot be interrupted.
Is it also necessary that the data it operates on isn't manipulated during execution ?, i.e. an instruction executing on another core accessing the atomic instruction's data.
I'm currently enrolled in the "Operating Systems" course at my college.
Is it also necessary that the data it operates on isn't manipulated during execution ?
Yes.
And that is why such instructions can be expensive to execute, possibly taking hundreds of cycles and including lock the CPUs' busses and checking no other CPUs (not just other cores: multi-socket systems have to be included) are accessing the affected memory.
See also this answer.
There are two concepts at work here:
1) Atomic instructions are those that a processor cannot interrupt.
2) Interlocked instructions are those that lock the memory bus and invalidate [sections of] the CPU caches.
An interlocked instruction will always be atomic. An atomic instruction might not be (and often is not) interlocked.
I know that in Asymmetric multiprocessing one processor can make all the scheduling decisions whilst the others execute user code only. But is it possible for a single-processor system to allow for multi-level queue scheduling? And why?
Certainly a single processor system can use multi-level queue scheduling (MLQS). The MLQS algorithm is used to decide which process to run next when a processor becomes available. The algorithm doesn't require that there be more than one processor in the system. As a matter of fact, the algorithm is most efficient if there is only one processor. In a multi-processor system the data structure would need some sort of locking to prevent it from being corrupted.
I was asked to anwer these questions about the OS context switch, the question is pretty tricky and I cannot find any answer in my textbook:
How many PCBs exist in a system at a particular time?
What are two situations that could cause a Context Switch to occur? (I think they are interrupt and termination of a process,but I am not sure )
Hardware support can make a difference in the amount of time it takes to do the switch. What are two different approaches?
What part of the OS is involved in managing the Context Switch?
There can be any number of PCBs in the system at a given moment in time. Each PCB is linked to a process.
Timer interrupts in preemptive kernels or process renouncing control of processor in cooperative kernels. And, of course, process termination and blocking at I/O operations.
I don't know the answer here, but see Marko's answer
One of the schedulers from the kernel.
3: A whole number of possible hardware optimisations
Small register sets (therefore less to save and restore on context switch)
'Dirty' flags for floating point/vector processor register set - allows the kernel to avoid saving the context if nothing has happened to it since it was switched in. FP/VP contexts are usually very large and a great many threads never use them. Some RTOSs provide an API to tell the kernel that a thread never uses FP/VP at all eliminating even more context restores and some saves - particularly when a thread handling an ISR pre-empts another, and then quickly completes, with the kernel immediately rescheduling the original thread.
Shadow register banks: Seen on small embedded CPUs with on-board singe-cycle SRAM. CPU registers are memory backed. As a result, switching bank is merely a case of switching base-address of the registers. This is usually achieved in a few instructions and is very cheap. Usually the number of context is severely limited in these systems.
Shadow interrupt registers: Shadow register banks for use in ISRs. An example is all ARM CPUs that have a shadow bank of about 6 or 7 registers for its fast interrupt handler and a slightly fewer shadowed for the regular one.
Whilst not strictly a performance increase for context switching, this can help ith the cost of context switching on the back of an ISR.
Physically rather than virtually mapped caches. A virtually mapped cache has to be flushed on context switch if the MMU is changed - which it will be in any multi-process environment with memory protection. However, a physically mapped cache means that virtual-physical address translation is a critical-path activity on load and store operations, and a lot of gates are expended on caching to improve performance. Virtually mapped caches were therefore a design choice on some CPUs designed for embedded systems.
The scheduler is the part of the operating systems that manage context switching, it perform context switching in one of the following conditions:
1.Multitasking
2.Interrupt handling
3.User and kernel mode switching
and each process have its own PCB