From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4C1BCCBF.7010400@domain.hid> Date: Fri, 18 Jun 2010 21:45:03 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4C1B7EB1.2040006@domain.hid> <4C1B8C04.3010900@domain.hid> In-Reply-To: <4C1B8C04.3010900@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] Fwd: problem in pthread_mutex_lock/unlock List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nero Fernandez Cc: xenomai@xenomai.org Gilles Chanteperdrix wrote: > Nero Fernandez wrote: >> On Fri, Jun 18, 2010 at 7:42 PM, Gilles Chanteperdrix >> > > wrote: >> >> Nero Fernandez wrote: >> > Hi, >> > >> > Please find an archive attached, containing : >> > - a program for testing context-switch-latency using posix-APIs >> > for native linux kernel and xenomai-posix-skin (userspace). >> > - Makefile to build it using xenomai >> >> Your program is very long to tell fast. But it seems you are using the >> mutex as if they were recursive. Xenomai posix skin mutexes used to be >> recursive by default, but no longer are. >> >> Also note that your code does not check the return value of the posix >> skin services, which is a really bad idea. >> >> -- >> Gilles. >> >> >> Thanks for the prompt response. >> >> Could you explain 'recursive usage of mutex' a little further? >> Are the xenomai pthread-mutexes very different in behaviour than regular >> posix mutexes? > > The posix specification does not define the default type of a mutex. So, > in short, the behaviour of a "regular posix mutex" is unspecified. > However, following the principle of least surprise, Xenomai chose, like > Linux, to use the "normal" type by default. > > What is the type of a posix mutex is explained in many places, starting > with Xenomai API documentation. So, no, I will not repeat it here. Actually, that is not your problem. However, you do not check the return value of posix services, which is a bad idea. And indeed, if you check it you will find your error: a thread which does not own a mutex tries to unlock it. Sorry, mutex are not semaphore, this is invalid, and Xenomai returns an error in such a case. -- Gilles.