Implyment read write lock with mutex

Using two mutexes[edit]

Raynal demonstrates how to implement an R/W lock using two mutexes and a single integer counter. The counter, b, tracks the number of blocking readers. One mutex, r, protects b and is only used by readers; the other, g (for "global") ensures mutual exclusion of writers. This requires that a mutex acquired by one thread can be released by another. The following is pseudocode for the operations:

Begin Read

• Lock r.
• Increment b.
• If b = 1, lock g.
• Unlock r.

End Read

• Lock r.
• Decrement b.
• If b = 0, unlock g.
• Unlock r.

Begin Write

• Lock g.

End Write

• Unlock g.

This implementation is read-preferring.^[

https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock#Using_two_mutexes

Lock Free queue with CAS (compare and swap)

do {
  p = ctx->tail;

  if ( __sync_bool_compare_and_swap(&ctx->tail, p, tmpnode)) {
    p->next=tmpnode;
    break;
  }
} while(1);

First a temporary variable, p, is assigned the same value of the tail of our queue. In this case ctx is short for “queue context”. Next we want to add our new node tmpnode to the end of our queue (make it the tail). If two threads are trying to do this at the same time, then one of them will succeed and one of them will fail. If the compare operation fails then the enqueue action will immediately loop again, trying to do another compare and swap operation, with the updated tail value. It will do this until it is successful, or until the heat death of the universe.

When the compare and set operation is successful, it means that we were able to change the value of the tail. The next line updates the previous tail’s next pointer to point to our new node. We don’t need to do this via a compare and set atomic operation, because if anyone else is trying to modify the the tail, they failed (or otherwise our compare would have failed). The break at the end exits the loop

https://schneems.com/2017/06/28/how-to-write-a-lock-free-queue/

https://www.codeproject.com/Articles/153898/Yet-another-implementation-of-a-lock-free-circular

tmux set mouse mode off for copy/paste

using the command below to turn mouse off for copy/paste

prefix : set -g mouse off

https://stackoverflow.com/questions/17445100/getting-back-old-copy-paste-behaviour-in-tmux-with-mouse

cpp template

cpp template zip file:

google link here

C++ class layout

class layout
https://www.evernote.com/shard/s260/sh/dfc7453b-e50f-46c0-b223-196bead364a9/c41f1cea8f38c1802d1941338b03d375

vtable:
https://en.wikipedia.org/wiki/Virtual_method_table

using CAS to implyment spinlock

#define CAS __sync_bool_compare_and_swap

bool __sync_bool_compare_and_swap (type *ptr, type oldval type newval, ...)
type __sync_val_compare_and_swap (type *ptr, type oldval type newval, ...)
These builtins perform an atomic compare and swap. That is, if the current value of *ptr is oldval, then write newval into *ptr.The “bool” version returns true if the comparison is successful and newval was written. The “val” version returns the contents of *ptr before the operation. 

static inline void my_spinlock(unsigned int *lock){
    while (!CAS(lock, 0, 1));
}
static inline void my_spinunlock(unsigned int *lock) {
    *lock = 0;
    //CAS(lock, 1, 0);
}

Esxi patch update

Esxi patch update:

esxcli software vib update -d /vmfs/volumes/5a023555-73045df5-66c5-0090fb60192a/ESXi650-201803001.zip

IRQL

What is IRQL and why is it important?

Interrupt Request Levels – aka IRQL’s.  If you develop device drivers or spend a lot of time debugging, IRQL’s are familiar territory for you.  An interrupt request level (IRQL) defines the hardware priority at which a processor operates at any given time. In the Windows Driver Model, a thread running at a low IRQL can be interrupted to run code at a higher IRQL.  The number of IRQL’s and their specific values are processor-dependent.

Processes running at a higher IRQL will pre-empt a thread or interrupt running at a lower IRQL.  An IRQL of 0 means that the processor is running a normal Kernel or User mode process.  An IRQL of 1 means that the processor is running an Asynchronous Procedure Call (APC) or Page Fault.  IRQL 2 is used for deferred procedure calls (DPC) and thread scheduling.  IRQL 2 is known as the DISPATCH_LEVEL.  

When a processor is running at a given IRQL, interrupts at that IRQL and lower are blocked by the processor.  

Therefore, a processor currently at DISPATCH_LEVEL can only be interrupted by a request from an IRQL greater than 2.  A system will schedule all threads to run at IRQL’s below DISPATCH_LEVEL – this level is also where the thread scheduler itself will run.  So if there is a thread that has an IRQL greater than 2, that thread will have exclusive use of the processor.  Since the scheduler runs at DISPATCH_LEVEL, and that interrupt level is now blocked off by the thread at a higher IRQL, the thread scheduler cannot run and schedule any other thread.  So far, this is pretty straightforward – especially when we’re talking about a single processor system.

On a multi-processor system, things get a little complicated.  Since each processor can be running at a different IRQL, you could have a situation where one processor is running a driver routine (Device Interrupt Level – aka DIRQL), while another processor is running driver code at IRQL 0.  Since more than one thread could attempt to access shared data at the same time, drivers should protect the shared data by using some method of synchronization.  Drivers should use a lock that raises the IRQL to the highest level at which any code that could access the data can run.  We’re not going to get too much into Locks and Deadlocks here, but for the sake of our discussion, an example would be a driver using a spin lock to protect data accessible at DISPATCH_LEVEL.  On a single processor system, raising the IRQL to DISPATCH_LEVEL or higher would have the same effect, because the raising of the IRQL prevents the interruption of the code currently executing.

That will actually wrap it up for this post.  It’s a fairly short post, but hopefully you now have a basic understanding of IRQL.  Until next time …