This example is tailored to be in line with the implementations of RwLock and Mutex. The only thing missing is an extra layer of indirection that has been omitted to not make this recipe even more complex. SomeOsSpecificFunctionalityHandle shouldn't contain actual implementations of lock and unlock, but instead, pass the calls onto a stored implementation that is specific to whatever OS you're using. For example, say you have a struct, windows::SomeOsSpecificFunctionalityHandle, for a Windows-based implementation and a struct, unix::SomeOsSpecificFunctionalityHandle, for a Unix-based implementation. SomeOsSpecificFunctionalityHandle should then, conditionally, depending on the operating system that is being run, pass its lock and unlock calls onto the correct implementations. These may have many more features. The Windows one could maybe have a awesome_windows_thing() function that might be useful to the unlucky Windows developer that needs it. The Unix implementation could have a confusing_posix_thing() function that does some very weird things that only Unix hackers would understand. The important thing is that our  SomeOsSpecificFunctionalityHandle should represent a common interface of the implementations. In our case, that means that every supported OS has the ability to lock and unlock the resource in question.