怎么以“等待”的方式获取文件句柄

如何以“等待”的方式获取文件句柄？
就像通过WaitForSingleObject等待mutex一样，windows有没有相关的API？

问题详情：
一个多线程的应用，每个线程都会获取某些文件的handle（通过createfile以独占方式获取），然后进行相关处理。因为多个线程有可能同时想要获取同一个文件的句柄，所以规定，如果一个线程无法获取某个文件的句柄（也有可能是被其他乱七八糟的进程占用了），就等待，直到获取句柄或者超时（30秒内未能获得句柄就不等了）。

目前，我所能想到的办法就只有轮询了，比如每秒钟尝试一次，30次还是拿不到handle就结束。但感觉太土了，不知道大家有没有什么更好的方法
------解决方案--------------------
文件关闭的时候，向线程发出一个通知或者执行一个回调
------解决方案--------------------

引用:

Quote: 引用:

文件关闭的时候，向线程发出一个通知或者执行一个回调

麻烦在于handle也有可能是被其他不受自己控制的应用程序占用

参见原文：
因为多个线程有可能同时想要获取同一个文件的句柄，所以规定，如果一个线程无法获取某个文件的句柄（也有可能是被其他乱七八糟的进程占用了），就等待，直到获取句柄或者超时

你关注的应该是文件，而不是句柄，句柄每次createfile都会不一样
------解决方案--------------------

引用:

Quote: 引用:

Quote: 引用:

你是 打开 一个 句柄 后 ，大家用， 
能不能 换一个思路， 
文件本身 不 共享
每人 打开 一下， 用完关闭。
其他人 30秒 内 看 能不能 打开。

我怎么觉得你理解错了楼主的意思呢。
楼主的意思是这个文件被其他进程打开了，而后楼主想去打开时，就会失败，但可能其他进程在30秒内就会关闭这个文件，因此，楼主想自己写的程序能否等待30秒，在30秒内能成功打开也OK。

那不就简单，打开失败的时候，启动一个定时器，定时30秒到，删除定时器并执行尝试

你再仔细看看楼主的描述，这个方法很土啊，楼主都说了。如果第5秒就可以打开了，还不得再等25秒啊？或者定时器1秒一次，但是否又耗资源呢，极限情况要尝试30次，虽说对现在CPU来说不算什么，但我总觉得没有像用WaitForSingleObject这样的方式来得优雅。
------解决方案--------------------
不是所有问题都会有优雅的解决办法.

赵老师经常教诲我们:  不要尝试优雅解决一个问题, 而是要在烂得不能再烂的摊子上重整山河.

不过, 楼主这种追求极致的精神, 值得我学习, 不是解决了问题就可以, 而是要思考更好的解决方案.