This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
pthreads: POSIX spec and Open POSIX Test Suite
- From: Michael Pederson <michael dot pederson at freescale dot com>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Fri, 20 Oct 2006 11:16:18 -0500
- Subject: [ECOS] pthreads: POSIX spec and Open POSIX Test Suite
Hello,
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.
http://posixtest.sourceforge.net/
https://sourceforge.net/projects/posixtest/
http://bugzilla.ecoscentric.com/show_bug.cgi?id=1000329
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.
Thanks,
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