WIN32 Synchronization

Question 1

Volatile Variables

Answer 1

• volatile quantifier informs the compiler that the variable must be fetched and stored everytime it is modified
• This decreases efficiency
• Cores can store data in cache, and since each core has its cache, we have no assurance that a variable will be visible to other threads.
• To ensure changes are visible to all cores we need memory barriers

Question 2

Interlocked functions

Answer 2

• Useful to manipulate signed numbers
• Limited to increment or decrement values
• Takes place in user space
  
  • no kernel call
  • easy to use
  • no deadlock risk
  • faster than any other alternative
  • variables need to be volatile

Question 3

Critical sections

Answer 3

• Can only be used to synchronize threads that are part of the same process
• Not kernel objects
• Since there is no call to kernel they are very efficient, fast mutexes
• Critical sections are initialized, not created, and deleted, not closed
• Only one thread at the time can enter the critical section
• They are recursive
• Spinlock variants can be used to make it more efficient:
  
  • InitializeCriticalSectionAndSpinCount
  • SetCriticalSectionSpinCount
  • should only be used:
    
    • on multi-core machines
    • When the CS is hold for few instructions
    • When there is high contention for the critical section among threads

Question 4

Mutexes

Answer 4

• kernel objects
• can be used for interprocess communication
• owned by a thread
• recursive
• a mutex can be polled to avoid blocking
• a mutex can be abandoned if the owning thread terminates without releasing it.
• CreateMutex:
  
  • returns new handle
  • lpsa: security settings (null)
  • fInitialOwner is a flag
    
    • if it is TRUE, the calling threads becomes the owner
  • lpszMutexName
• BOOL ReleaseMutex(HANDLE)
  
  • fail if calling Thread doesn’t own it
• will return WAIT_ABANDONED_0 if abandoned (wait for multiple objects)
• OpenMutex:
  
  • DesiredAccess:
  • inheritHandle
  • lpszMutexName
  • Allows synching among different processes
  • CreateMutex in one thread, open in the other (in case their CreateMutex fails)

Question 5

Semaphores

Answer 5

Must be:

• Created
• Waited for
• Released
• Closed

CreateSemaphore params:

• lpsa: security atttributes (usually NULL)
• cSemInital: is initial value for the sem.
• cSemMax: max value of the semaphore
• lpszSemName: the name of the semaphore, can be nulled if manipulation happens through handle

ReleaseSemaphore

• hSemaphore
• cReleaseCount: value to add to counter of semaphore
• lpPreviousCount: previous value of the counter

NB: It is possible to release multiple units in an atomic way, but it’s not possible to wait in the same manner;

Question 6

Events

Answer 6

• Kernel synchronization objects
• They:
  
  • are used to send signal to threads indicating something occurred (like condition variables and Unix signals)
  • can release multiple threads simultaneously when a single event is signaled
• Must:
  
  • be created: CreateEvent
  • signalled: PulseEvent / SetEvent
  • reset: Automatic or Manual (ResetEvent(handle))
  • Waited for: WFSO or WFMO
• Events need to be waited for
  
  • Be sure of what you are doing when using WFMO, because it waits for all events to become signalled at the same time
    
    • unfortunatly some may reset before the thread gets released.
• CreateEvent:
  
  • lpsa -> null
  • fManualReset
  • fInitialState: true if we want to be initially be signaled
  • eventName: possible to use OpenEvent to open a named event by another process.
• Warnings:
  
  • Setting an event that is already set has no effect
    
    • There is no memory
    • Multiple SetEvent may be lost
  • Resetting event already reset has no effect
  • PulseEvent is unreliable: should not be used, it may be lost
    
    • Pulse event releases only the threads that are in waiting state, if a thread is waiting for the event but was woke up by the kernel momentarily, the pulseevent will be lost.
    • It exists for backward compatibility

Question 7

Semaphore Throttles

Answer 7

• Objective:
  
  • prevent performance degradation when high number of contenders for shared resourced
• Strategy: use semaphore to fix the maximum amount of running threads
  
  • The boss thread:
    
    • creates semaphores, sets maximum value to a reasonable number
  • Worker thread must get a semaphore unit before working
• Variations: some workers may acquire multiple units (using more resources leads to waiting more throttles)

Question 8

Thread Pool

Answer 8

• The user initializes a thread pool queue, creates work objects (tasks) and inserts task into a queue.
• Windows automatically:
  
  • assigned a task to a worker thread that will work on the task
  • when it completes it may be assigned to a new task
• Worker threads:
  
  • can run concurrently on separate processors
  • invokes all callbacks without stopping (no context switch)
  • Callback functions (task code) should not use ExitThread (this would terminate the worker thread

Question 9

SetEvent

Answer 9

• If Manual-reset
  
  • the event remains signaled until some thread calls ResetEvent for that event
  • Any thread that was waiting on the event will be released
• if Auto-reset
  
  • the event remains signalled until a single thread waiting is released
  • when the thread is released the event is reset

Question 10

PulseEvent

Answer 10

• Manual-reset:
  
  • Allows to release all threads currently waiting on a manual-reset event, then automatically resets.
• Automatic-reset
  
  • If a thread is in waiting state it gets released, then reset.