D3d12 provides synchronization API's with resource barriers and fences. I'm not familiar with vulkan's API but the name “binary semaphore” telling me that we can have locking system in vulkan.

I understand the purpose of resource barriers so put it aside; but using fences to force two or more command queues to wait and signal on a shared fence to provide locking system is making me scratching my head for hours.

For example, If we have two queues and one fence initialized with value 1 , then each queue has a wait and signal operation at the start of the critical section of their command and a signal operation at the end. First signal decrements the value to 0 and last one increments it to 1. The wait operation expects the fence value to be 1. I know every command queue operation are atomic themselves but you can see that in this ill-formed implementation that I described, there is no guarantee that two command queue won't exceed the wait operation at the same time(I don't have the wait and signal as one atomic operation).

As you have guessed, I'm not a multithreading expert or anything. Take me as beginner. So any tip and enlightenment from your knowledge will save me days.

I had no idea you could even use a fence with more than one queue. I've always used it with one.

@undefined Thanks for the reply.

Yeah I use one fence for each queue too, but just for one use case : when one queue has to wait for a specific fence of another queue; So we give them an order in this way.

But my problem is when that there is a "race" for them to access a shared resource. I think we can do this with binary semaphore in vulkan.

Do have any idea how to achieve this?

RRRella said:
any tip and enlightenment from your knowledge will save me days

When i do threading, i always do lock-less. I just wait the threads to finish and thats all, i never do complex syncing or semaphores (which are in my case are just volatile declared longs instead of os assisted real semaphores if i have to do them). So i cant help you with any precise advice. I dont think i am smart enough to understand the technical issue you are discussing.

But one important thing to note. If you are not sure how to use a feature properly, and it might could injure the stability and reliability of the product… then the wisest thing is not to use it. You can access your graphics api from one thread and you will still not lose any notable speed i think. Dont let yourself diverted from your goals by problems like this. There is no need to turn a 5 minute long programming problem into a 5 month long just to have plus 5 fps.

I suppose you could just use a fence for each queue and then call WaitForMultipleObjects. I'm not sure of the details of your use case.