diff --git a/SyncPrim/sync-6.md b/SyncPrim/sync-6.md index f58385c..085bf10 100644 --- a/SyncPrim/sync-6.md +++ b/SyncPrim/sync-6.md @@ -17,9 +17,9 @@ So, let's start. Sequential lock -------------------------------------------------------------------------------- -So, what is it `seqlock` synchronization primitive and how it works? Let's try to answer on these questions in this paragraph. Actually `sequential locks` were introduced in the Linux kernel 2.6.x. Main point of this synchronization primitive is to provide fast and lock-free access to shared resource Since the heart of `sequential lock` synchronization primitive is [spinlock](https://0xax.gitbooks.io/linux-insides/content/SyncPrim/sync-1.html) synchronization primitive, `sequential locks` work in situations where the protected resources are small and simple. Additionally write access must be rare and also should be fast. +So, what is it `seqlock` synchronization primitive and how it works? Let's try to answer on these questions in this paragraph. Actually `sequential locks` were introduced in the Linux kernel 2.6.x. Main point of this synchronization primitive is to provide fast and lock-free access to shared resource. Since the heart of `sequential lock` synchronization primitive is [spinlock](https://0xax.gitbooks.io/linux-insides/content/SyncPrim/sync-1.html) synchronization primitive, `sequential locks` work in situations where the protected resources are small and simple. Additionally write access must be rare and also should be fast. -Work of this synchronization primitive is based on the sequence of events counter. Actually a `sequential lock` allows to free access to a resource for readers, but each reader must check existence of conflicts with a writer. This synchronization primitive introduces special counter. The main algorith of work of `sequential locks` is simple: Each writer which acquired a sequential lock increments this counter and additionaly acquires a [spinlock](https://0xax.gitbooks.io/linux-insides/content/SyncPrim/sync-1.html). When this writer will finish, it will release acquired spinlock to give access to other writers and increment the counter of a sequential lock again. +Work of this synchronization primitive is based on the sequence of events counter. Actually a `sequential lock` allows to free access to a resource for readers, but each reader must check existence of conflicts with a writer. This synchronization primitive introduces special counter. The main algorithm of work of `sequential locks` is simple: Each writer which acquired a sequential lock increments this counter and additionaly acquires a [spinlock](https://0xax.gitbooks.io/linux-insides/content/SyncPrim/sync-1.html). When this writer will finish, it will release acquired spinlock to give access to other writers and increment the counter of a sequential lock again. Read only access works on the following principle gets value of a `sequential lock` counter before it will enter into [critical section](https://en.wikipedia.org/wiki/Critical_section) and compares it with the value of the same `sequential lock` counter at the exit of critical section. If their values are equal, this means that there weren't writers for this period. If their values are not equal, this means that a writer has incremented the counter during the [critical section](https://en.wikipedia.org/wiki/Critical_section). This conflict means that reading of protected data must be repeated. @@ -177,7 +177,7 @@ static inline unsigned read_seqbegin(const seqlock_t *sl) } ``` -In its turn The `read_seqcount_begin` function calls the `raw_read_seqcount_begin` function: +In its turn the `read_seqcount_begin` function calls the `raw_read_seqcount_begin` function: ```C static inline unsigned read_seqcount_begin(const seqcount_t *s) diff --git a/contributors.md b/contributors.md index b05ce35..9aef799 100644 --- a/contributors.md +++ b/contributors.md @@ -94,3 +94,4 @@ Thank you to all contributors: * [Jeremy Cline](https://github.com/jeremycline) * [Kavindra Nikhurpa](https://github.com/kavi-nikhurpa) * [Connor Mullen](https://github.com/mullen3) +* [Alex Gonzalez](https://github.com/alex-gonz) diff --git a/interrupts/interrupts-1.md b/interrupts/interrupts-1.md index d22e602..4b8e840 100644 --- a/interrupts/interrupts-1.md +++ b/interrupts/interrupts-1.md @@ -227,7 +227,7 @@ And the last `Type` field describes the type of the `IDT` entry. There are three * Trap gate * Task gate -The `IST` or `Interrupt Stack Table` is a new mechanism in the `x86_64`. It is used as an alternative to the legacy stack-switch mechanism. Previously The `x86` architecture provided a mechanism to automatically switch stack frames in response to an interrupt. The `IST` is a modified version of the `x86` Stack switching mode. This mechanism unconditionally switches stacks when it is enabled and can be enabled for any interrupt in the `IDT` entry related with the certain interrupt (we will soon see it). From this we can understand that `IST` is not necessary for all interrupts. Some interrupts can continue to use the legacy stack switching mode. The `IST` mechanism provides up to seven `IST` pointers in the [Task State Segment](http://en.wikipedia.org/wiki/Task_state_segment) or `TSS` which is the special structure which contains information about a process. The `TSS` is used for stack switching during the execution of an interrupt or exception handler in the Linux kernel. Each pointer is referenced by an interrupt gate from the `IDT`. +The `IST` or `Interrupt Stack Table` is a new mechanism in the `x86_64`. It is used as an alternative to the legacy stack-switch mechanism. Previously the `x86` architecture provided a mechanism to automatically switch stack frames in response to an interrupt. The `IST` is a modified version of the `x86` Stack switching mode. This mechanism unconditionally switches stacks when it is enabled and can be enabled for any interrupt in the `IDT` entry related with the certain interrupt (we will soon see it). From this we can understand that `IST` is not necessary for all interrupts. Some interrupts can continue to use the legacy stack switching mode. The `IST` mechanism provides up to seven `IST` pointers in the [Task State Segment](http://en.wikipedia.org/wiki/Task_state_segment) or `TSS` which is the special structure which contains information about a process. The `TSS` is used for stack switching during the execution of an interrupt or exception handler in the Linux kernel. Each pointer is referenced by an interrupt gate from the `IDT`. The `Interrupt Descriptor Table` represented by the array of the `gate_desc` structures: