Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
BroadcastCommunity.qnx.com will be offline from May 31 6:00pm until June 2 12:00AM for upcoming system upgrades. For more information please go to https://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc28418
Forum Topic - Defect of pthread_mutex_trylock implementation: (3 Items)
   
Defect of pthread_mutex_trylock implementation  
In pthread_mutex_trylock()

----------
	// Static intialized. Do an immediate tineout so no threads block.
	if(owner == _NTO_SYNC_INITIALIZER) {
		(void)TimerTimeout_r(CLOCK_REALTIME, _NTO_TIMEOUT_MUTEX, NULL, NULL, NULL);
		if((ret = SyncMutexLock_r((sync_t *)mutex)) != EOK) {
			return ((ret == ETIMEDOUT) ? EBUSY : ret);
		}

		++mutex->__count;
		return EOK;
	}
----------
It is illegal to use CLOCK_REALTIME for setting up zero timeout here (just like anywhere else!). If system clock is 
adjusted (rewound back) in between of TimerTimeout() and SyncMutexLock_r() calls, the thread will block until clock 
catches up to the realtime value that was there at the moment of TimerTimeout call or until mutex is unlocked. For 
timeouts only CLOCK_MONOTONIC clock should be used.
Re: Defect of pthread_mutex_trylock implementation  
I think I'm right in saying that since this is an immediate timeout,
_NTO_TIMEOUT_IMMEDIATE is set on the thread's timeout_flags which will
result in short-cutting virtually all of the clock logic (i.e. the clock
selected is actually not important).

Are you observing a runtime problem?
Re: Defect of pthread_mutex_trylock implementation  
> I think I'm right in saying that since this is an immediate timeout,
> _NTO_TIMEOUT_IMMEDIATE is set on the thread's timeout_flags which will
> result in short-cutting virtually all of the clock logic (i.e. the clock
> selected is actually not important).
> 
> Are you observing a runtime problem?


No, I don't. Actually, I don't dig into the kernel code unless absolutely unavoidable - I do have plenty of my own work 
to do.
If it will work - that's fine, but using CLOCK_REALTIME makes user-level code dependent on specific detail of kernel 
implementation (what is bad) and also it makes user-level code look dubious for anybody who is not familiar with kernel 
implementation details (what is also bad).