atomic and mutex never ensure the execution order of threads

podboq — Thu, 10 Sep 2026 13:02:35 +0000

synopsis

whether one thread runs first or the other,is determined by the operating system's scheduling,which naturally results in a disorderly sequence.atomic and mutex can't guarantee the order.

Each core of a modern CPU has its own private L1/L2 cache and shares a L3 cache.When thread 1 modifies data,for performance reasons,it does not immediately write it back to main memory.Instead,it first writes it to the core's Store Buffer,and then asynchronously flushes it back to the cache/main memory.At this time,the core where thread 2 is located is completely unaware of this modification,and it still reads the old value from its own cache.Supplementary:The CPU has the MESI cache coherence protocol,but it can only guarantee "eventual cache coherence" and cannot guarantee "immediate visibility".The Store Buffer is a performance optimization designed to mask the delay of cache coherence.

When the compiler enables optimization(such as O2),it will directly cache frequently accessed variables in registers,without reading or writing memory throughout the process.For example,if a flag bit is repeatedly read in a loop,the compiler may only read memory the first time,and always read from the register thereafter,completely ignoring any changes made to the memory value by other threads.

std::atomic

It automatically prevents the compiler caching value in registers,ensuring every read and write access memory directly.

Automatically insert CPU memory barriers of the corresponding level to fore a flush of the Store Buffer and invalidate the cache,ensuring that modifications are visible to other threads.

At the same time,it ensures the atomic of single read-write operations,preventing the torn values during reads.

std::mutex

The semantics of mutex locks inherently include a complete memory barrier:the acquire semantics are executed when locking,and the release semantics are executed when unlocking.As long as both threads correctly lock/unlock before and after accessing shared data,visibility and atomic are naturally guaranteed.

Applicable scenarios:Scenarios where shared data is a complex structure and requires multiple steps of operation;the disadvantage is that the overhand is greater than that of atomic,with thread switching costs.

Memory Fence

This is a more fundamental mechanism,akin to manually inserting "synchronization points",which forces the CPU to flush the store buffer and invalidation read buffer,ensuring the read-write order and visibility before and after the barrier.

C++ standard:
std::atomic_thread_fence

Windows:
MemoryBarrier()

GCC:
_sync_synchronize()

PostMessage: worker thread post message to UI thread

podboq — Thu, 10 Sep 2026 08:17:43 +0000

Synopsis

PostMessage is one function of Windows API,worker thread can post message to UI thread via PostMessage

BOOL PostMessage(
HWND hWnd, //target window hand
UINT Msg, //message type, case in callback WndProc
WPARAM wParam, //true message
LPARAM lParam //true message
);

Demo code

#include <windows.h>

#define WM_RESULT (WM_USER + 1)

static HWND g_hWnd = NULL;
static HWND g_hStatic = NULL;

DWORD WINAPI WorkerThread(LPVOID)
{
    int sum = 0;
    for (int i = 1; i <= 100; ++i)
    {
        sum += i;
    }
    Sleep(1000);
    PostMessage(g_hWnd, WM_RESULT, (WPARAM)sum, 0);
    return 0;
}

LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wp, LPARAM lp)
{
    switch (msg)
    {
    case WM_CREATE:
    {
        g_hStatic = CreateWindowA("STATIC", "RESULT:waiting...", WS_CHILD | WS_VISIBLE, 20, 70, 260, 24, hWnd, NULL, NULL, NULL);
        CreateThread(NULL, 0, WorkerThread, NULL, 0, NULL);
    }
    break;

    case WM_COMMAND:
        if (LOWORD(wp) == 1)
        {
            CreateThread(NULL, 0, WorkerThread, NULL, 0, NULL);
        }
        break;

    case WM_RESULT:
    {
        char buf[64];
        wsprintfA(buf, "RESULT:%d", (int)wp);
        SetWindowTextA(g_hStatic, buf);
    }
    break;

    case WM_DESTROY:
        PostQuitMessage(0);
        break;

    default:
        return DefWindowProcA(hWnd, msg, wp, lp);
    }
    return 0;
}

int WINAPI WinMain(HINSTANCE hInst, HINSTANCE, LPSTR, int nCmdShow)
{
    WNDCLASSA wc = {0};
    wc.lpszClassName = "PostMsgDemo";
    wc.hInstance = hInst;
    wc.lpfnWndProc = WndProc;
    wc.hbrBackground = (HBRUSH)(COLOR_BTNFACE + 1);
    RegisterClassA(&wc);

    g_hWnd = CreateWindowA("PostMsgDemo", "PostMessage Demo", WS_OVERLAPPEDWINDOW & ~WS_THICKFRAME, 400, 300, 320, 180, NULL, NULL, hInst, NULL);
    ShowWindow(g_hWnd, nCmdShow);
    UpdateWindow(g_hWnd);

    MSG msg;
    while (GetMessage(&msg, NULL, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return (int)msg.wParam;
}

Complie and Run

cl /nologo PostMessage.cpp /link user32.lib kernel32.lib /subsystem:windows

Analysis

DispatchMessage is the really point where WndProc be called

while(GetMessage(&msg,NULL,0,0)){} This loop never finish on its own.This loop hangs here after program startup,processes message when they come,and just hangs when free.When you click the x in the top right corner to send WM_QUIT,and GetMessage returns False,this loop exits.I feel this loop hangs around like a trigger

DEV Community: podboq