[ECOS] pthreads: POSIX spec and Open POSIX Test Suite

Michael Pederson michael.pederson@freescale.com
Fri Oct 20 16:16:00 GMT 2006


I'm looking at test cases from the Open POSIX Test Suite which are 
failing on eCos.  That project appears to be Intel-driven and is not 
related to the Open Group.  The tests appear to read the spec strictly. 
  In the case of bug #1000329 (which I should have just raised here), it 
seems as though that test refers to an older POSIX spec.


Another of the tests which fails deals with the pthread_mutex_trylock 
function (Open POSIX Test Suite, 
conformance/interfaces/pthread_mutex_trylock/4-1.c).  The test has a 
thread lock a mutex then trylock that mutex.  The eCos implementation 
returns EDEADLK while the test code expects EBUSY.

The POSIX spec has a single section for functions pthread_mutex_lock, 
_unlock, and _trylock.  In the error codes section, each error code is 
preceded by qualifying statements regarding the function to which it 
applies.  The spec states that trylock "shall fail with EBUSY if the 
lock could not be acquired because it was already locked".  This wording 
was updated from "will" in an older spec to "shall".  The spec lists the 
EDEADLK error under the qualifier "The pthread_mutex_lock() function may 
fail if:".

The eCos implementation appears to go above and beyond the spec 
returning the error that is most informative, since EDEADLK indicates 
that the lock is locked, or EBUSY, and that the lock owner is the 
caller, or EDEADLK.  It makes the spec seem loose that this sort of 
implementation makes sense but doesn't appear to be specified.

In the bug report I mentioned, Jonathan points to a pthreads man page. 
While I have the understanding that there is not a single Linux pthreads 
implementation, does eCos generally follow the lead of another pthreads 
implementation?  In other words, is the Open Group POSIX spec a de jure 
standard, and if so what is the de facto standard?

I suppose I am confused about the extent to which the POSIX spec 
reflects reality, and I'm looking for any discussion about how the eCos 
implementation agrees with others in order to better understand whether 
the Open POSIX Test Suite cases are just naive in their strict reading 
the POSIX spec or if the project of a single POSIX test suite for all 
implementations is naive when there's lots of wiggle room in the POSIX 
spec and implementations disagree on things.

Michael Pederson

Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list