This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]