我弄了个多线程的资源管理器，
但是当一个客户端在open后，进行read挂住时，
另一个客户端进行open并不能得到响应啊！！！
怎么回事？
我看相关线程有以下状态：
旧的客户端是处于reply挂起状态，因为资源管理器接收到消息，在处理中挂起，还没reply，可以理解。
新的客户端是处于reply挂起状态，这个说明资源管理器是接收到消息，还没reply。
资源管理器进程有多个线程，
１个处于receive挂起状态的，这个应该是等待接收新的客户端请求的，正常。
１个处于sem挂起，这个是处理旧的客户端read挂起，可以理解。
１个处于condvar挂起？？？？？？？？？？
这个是什么状态啊，推测是新的客户端处理线程，但不知道为什么会这样啊。
求助高手！！！！！！！！！
condvar如何避免？？？？？？
你的io_read()处理，即使没有数据可以还给客户端，函数本身也是要返回的，正确的做法是return _RESMGR_NOREPLY; 我猜你是sem_wait()另外一个事件发生了。
为了保证文件操作的正确性，在一个瞬间，对同一个文件只能进行一种操作；像你现在的做法，因为io_read()没有返回，资源管理器认为read操作没有结束，是不会让第二个open操作发生的。
你可以在sem_wait()前解除这个限制。
.....
iofunc_attr_unlock(ocb->attr);
sem_wait(...);
iofunc_attr_lock(ocb->attr):
.....
果然是专家，
相当感谢啊~~~~
请问下，这个问题是否可以理解为qnx缺省对多线程的资源管理器进行了保护，防止多个thread同时对一个文件/device进行读写？
如果我要解除这个限制，是不是要如下实现
my_read/my_write…(…)
{
iofunc_attr_unlock(ocb->attr); <–额外添加
…
do_a_cost_much_time_task();
…
iofunc_attr_lock(ocb->attr); <–额外添加
}
这样才能故意将ocb的lock count解除，让其他线程可以open进来
这种做法会不会有什么副作用，假设该资源管理器内信息不需要保护
再补充个问题，为什么用sopen无法解决文件共享问题？
我用2个client先后sopen一个文件，第二个client在sopen时候还是会挂住