Thanks.
I just check creating two threads loop waiting, one taking a lock first
without releasing it. The second thread seems to wait indefinitely to get
it (I let this run several hours). So you're right, there's no time out
for this function, which is the behaviour I suspected.
Well, I didn't play yet with thread-safe queues but I will look at the
samples.
Thanks for your help,
Mohan a ecrit :
> The function panel help for the CmtStatus return value is shared among
> all of the multi-threading functions. So, eventhough one possible
> value for CmtStatus error is a time-out, this does not mean that all
> multi-threading functions that return CmtStatus will return a time-out
> error.
>
> In particular, CmtGetLock should not return a time-out error,
as there
> is no way for the user to set a time-out for the lock. As far as I can
> see, only the thread-safe queue functions can return a time-out error,
> as only these objects support a user-settable time-out interval. So
> even if other synchronization objects internally (at the system level)
> time-out, the user would only get a "-14910, System error occurred"
> CmtStatus, and not a time-out.
>
> If you want to set a time-out for your CVI lock objects, you can do
> this by processing events when you wait on the lock, and have a CVI
> timer, in whose callback you can check if the time-out period has
> elapsed. If you want to set a time-out without processing events while
> waiting, then you should consider using a Win32 mutex and the
> WaitForSingleObjectEx SDK function (see the Windows SDK documentation
> for more information on this).
>
> Regards,
> Mohan,
> National Instruments
