chaelim

Async IO Programming

---

Design Pattern

• Proactor
• Proactor vs Reactor
• The Reactor patterns involve synchronous I/O, whereas the Proactor pattern involves asynchronous I/O. In Reactor, the event demultiplexor waits for events that indicate when a file descriptor or socket is ready for a read or write operation. The demultiplexor passes this event to the appropriate handler, which is responsible for performing the actual read or write.
• In the Proactor pattern, by contrast, the handler—or the event demultiplexor on behalf of the handler—initiates asynchronous read and write operations. The I/O operation itself is performed by the operating system (OS). The parameters passed to the OS include the addresses of user-defined data buffers from which the OS gets data to write, or to which the OS puts data read. The event demultiplexor waits for events t

chaelim

// Build: g++ -O3 -std=gnu++14 -m64 MonoTime.cc -lpthread -o MonoTime -mmemory-model=tso
//
// Dave Dice -- blogs.oracle.com/dave

#include <thread>
#include <chrono>
#include <iostream>
#include <vector>
#include <mutex>
#include <random>

chaelim

// InflatableSeqLock
// Copyright(C) 2016 Oracle and/or its affiliates
// Dave Dice : https://blogs.oracle.com/dave
//
// Remarks:
// *  Implements composite writer mutex and seqlock in a single word-sized lock.   
//    Allows optimistic reading and pessimistic writing.
//    Readers don't write to shared synchronization metadata, which helps avoid
//    coherence traffic.  Readers must tolerate observing inconsistent state, however.  
// *  Writer mutex is based on LIFO-CR lock from http://arxiv.org/abs/1511.06035.  

chaelim

Obfuscating memory pointer using EncodePointer/DecodePointer APIs

https://msdn.microsoft.com/en-us/library/bb432254%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/library/bb432242(v=vs.85).aspx

chaelim

Opened log file 'FlushProcessWriteBuffers.log'
0: kd> x nt!*FlushProcessWriteBuffers*
fffff800`0226da70 nt!KeFlushProcessWriteBuffers = <no type information>
fffff800`0225a9d0 nt!NtFlushProcessWriteBuffers = <no type information>
fffff800`022a0720 nt!ZwFlushProcessWriteBuffers = <no type information>
fffff800`0226e3cc nt!KiFlushProcessWriteBuffersTarget = <no type information>
0: kd> u fffff800`0225a9d0
nt!NtFlushProcessWriteBuffers:
fffff800`0225a9d0 33c9            xor     ecx,ecx
fffff800`0225a9d2 e999300100      jmp     nt!KeFlushProcessWriteBuffers (fffff800`0226da70)

chaelim

========================================================================
FIND PAGE FAULT IDT (KiTrap0E)
========================================================================
kd> !pcr 0
    Find "KPCR for Processor 0 at fffff80001176000:"
kd> dt _KPCR fffff80001176000
    Find "+0?38 IdtBase          : 0xfffff800`03694070  _KIDTENTRY64"
    
kd> r? $t0=(_KIDTENTRY64 *)0xfffff800`03694070; .for (r $t1=0; @$t1 <= 13; r? $t0=(_KIDTENTRY64 *)@$t0+1) { .printf "Interrupt vector %d (0x%x):\n", @$t1, @$t1; ln @@c++(@$t0->OffsetHigh*0x100000000 + @$t0->OffsetMiddle*0x10000 + @$t0->OffsetLow); r $t1=$t1+1 }

chaelim

VC stdlib.h macro

/* _countof helper */
#if !defined(_countof)
#if !defined(__cplusplus)
#define _countof(_Array) (sizeof(_Array) / sizeof(_Array[0]))
#else
extern "C++"
{
template <typename _CountofType, size_t _SizeOfArray>

chaelim

/****************************************************************************
*
*   BrokenGuardPage.cpp
*  
*   Just use following commands for compile:
*       cl BrokenGuardPage.cpp
*
*   Written by CS Lim (9/26/2006)
*
***/

chaelim

#include <windows.h>
#include <process.h>
#include <stdio.h>
#include <intrin.h>

#define DO_FLUSH

unsigned __stdcall thread(void* p)
{
   unsigned __int64 t1 = __rdtsc();

chaelim

    // Note From MSDN:
    //    In past versions of the Visual C++ compiler, the _ReadWriteBarrier
    //    and _WriteBarrier functions were enforced only locally and did not
    //    affect functions up the call tree. In Visual C++ 2005 and later,
    //    these functions are enforced all the way up the call tree.


// Intel and AMD (x86 and AMD64) enforces strong ordering (program ordering)
// except a store followed by a load (the store becomes visible before
// the load executes) http://en.wikipedia.org/wiki/Memory_ordering