There is a lot written about windows kernel objects, but not so much for Dxgk style objects. If you ever look how windows share DXGI resources across processes, you will notice the handles created live on "dwm.exe" with the type DxgkSharedResource.
There is in fact userland API to manage those objects, and it is directed to graphics drivers vendors to develop UMD drivers for graphic cards. When you create a DXGI texture, the driver ultimatelly calls D3DKMTCreateAllocation wich creates the dxgk kernel object that hold it on the system.
There is two important memory pointers that those object use to hold:
- Private Runtime Data: This is a struct defined and filled by the OS (dxgi user) and represent what the system known about the resource, like size, format..., This struct changes its elements sometimes across windows dritribs. Fun fact: you will think microsoft provides driver developers with headers for this structures, but if you peek into nvidia leaked drivers you can watch the grind around reverse engineering those structures.
- Private Driver Data: This is a struct defined by the driver developer (nvidia/ati...) and represents what the driver vendor knows about the resource, like addresses and aligned sizes that only driver implementator and its little computer knows. Nvidia is used to modify this struct on every **** driver release.
So thats how both DXGI and driver share information at resource level. Having this in mind, using this API is simple, years ago, the header for those methods was not provided by microsoft wich required to create a load thunk, nowdays microsoft provides it under <D3dkmthk.h>
When using shared textures, there is a nice feature called keyed mutex. When you create a texture with keyed mutex support, you will see an additional kernel object DxgkSharedKeyedMutexObject appears on dwm process, unlike a normal mutex that will hold the lock condition this one also locks for a key, and set the key when unlock. To create this object the driver calls D3DKMTCreateKeyedMutex2 and use that family of API to manage them.
So what about creating standalone keyed mutex to be used as synchronization, ipc, high precision clock source... well its possible and here is a small library to do it. The resolution of the lock timeout is really precise and lightweight
The syscalls for this operations appeared on Windows Server 2008 - R2 (prior to win7) There's a second version of this API thats includes private data buffer sections (ill upload upon request), readable upon lock and writable on creation and unlock. The syscall for version 2 appeared on windows server 2012 (post win7 / pre win8)
TLDR: A keyed mutex acts as a normal mutex but apart of waiting to be unlocked, it also waits that the lock key match the internal key of the object. The internal key is set upon creation and on each unlock operation. Keyed mutex are thread-safe and can be used between different processes.