Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups: comp.os.linux.development.apps
Subject: Re: pthred_con_timewait problem
Date: Tue, 29 Jan 2013 15:19:31 +0000
Lines: 18
Message-ID: <87pq0o10fw.fsf@sapphire.mobileactivedefense.com>
References: <InRNs.867$OE1.126@newsfe26.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: individual.net uIRlcRxs9HnBRjX3wzUTQwxIY6I0td7AmatrwCJe0DSqc7EcKNfUS6sMr2AQhA7Xo=
Cancel-Lock: sha1:8WltYHWprHX2tmrc+tGsZxVxk0w= sha1:R9TMgYuIEBYYQMmAbJrW51DbiZc=
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Xref: csiph.com comp.os.linux.development.apps:559

ephlodur <ephlodur@linuxmail.org> writes:

[...]

>         	_ret = pthread_cond_timedwait(&_event_id, &_m_mutex, &ts);
> 			unlock();
>
> but when ever I make that call it always return with EPERM

According to the UNIX(*) standard,

	[EPERM]
		The mutex type is PTHREAD_MUTEX_ERRORCHECK or the
		mutex is a robust mutex, and the current thread does
		not own the mutex.

This would mean that the thread invoking pthread_cond_timedwait didn't
lock the _m_mutex mutex.