So, it's either CreateEvent WaitForSingleObject, or PostThreadMessage MsgWaitForMultipleObjects. I'm not sure what they do, is it possible for each thread to have it's own message loop or something?

By the way, there is some odd warning against WaitForSingleObject, something about deadlock if you use COM and multiple threads and something, I'm not sure if this applies to me.

https://marc.durdin.net/2012/08/waitforsingleobject-why-you-should-never-use-it/

i=0
li=0
dword ring[0x20]={0}    

ring[i+1]="C:/loadmepls.jpg"
MemoryFence
ring[i]=1
i+=2    

while true:
    if ring[i]==0:
        sleep or some other winapi function that will pause the thread
    else:
        path = ring[i+1]
        decompressed_data = decompress(path)
        ring[i+1] = decompressed_data
        MemoryFence
        ring[i]=0
        i+=2    

if ring[li]==0:
    decompressed_data = ring[li+1]
    load_to_gpu(decompressed_data)
    li+=2    

According to this http://www.bogotobogo.com/cplusplus/multithreading_win32A.php , there are 3 different ways to create a thread: CreateThread, _beginthread and _beginthreadex. The first one doesn't create thread-local storage for you, so this is the one I will use.

Thread-local storage is, um, something like a global variable, but its value is different for each thread. It's often used by some memory allocators, and when there are many threads. I will use only 2 threads for now, so I'll live without it. I'll just use a local variable instead of this thread-local global. Also looks like windows xp doesn't support something about TLS, and I want my programs to work even there.

Also, if I malloc'd some memory in [main thread], I shouldn't free it in the [worker thread], and vice versa?

a single-reader single-writer ring buffer FIFO, with a size which evenly divides the overflow of one of the available unsigned integer types, can unconditionally be implemented safely using only a memory barrier

false sharing

This occurs when each individual processor is attempting to use data in another memory region and attempts to store it in the same cache line. This causes the cache line -- which contains data another processor can use -- to be overwritten again and again.

Effectively, different threads make each other wait by inducing cache misses in this situation.

An extreme symptom of poor caching in RAM memory (which is probably not what you mean in this context) is so-called thrashing. This occurs when the process continuously generates page faults (e.g. accesses memory which is not in the current page) which require disk access.

Cache-Lines size is (typically) 64 bytes.