[Bug nptl/12674] sem_post/sem_wait race causing sem_post to return EINVAL

["dhatch at ilm dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12674

--- Comment #5 from Don Hatch <dhatch at ilm dot com> 2011-04-19 22:06:36 UTC ---
(In reply to comment #4)
> There cannot be any question that it is illegal.  You pass a pointer to the
> semaphore to sem_post and just because it is half-finished and a sem_wait
> succeeds this doesn't mean the call must be done.  As I said, only when the
> sem_post call also returns is the semaphore unused.

Hi Ulrich,

Sorry if it seems I am belaboring this.
I understand your assertion; it's the same thing you said
in your first reply (Comment 1), right?
But it's not clear to me on what basis you are making this assertion.
Is it based on the spec,
or are you stating what you believe to be common sense and obvious?

If it is from the spec, please say so (quoting the relevant passage if
possible)
and that will end the discussion.
(And I will open a bug report against the man page,
asking for it to be amended to include the clarifying passage from the spec.)

But if you are arguing from common sense, then I think you are certainly wrong
about it being obvious or the only reasonable interpretation.
One could equally well say from common sense
"you pass to mutex_unlock a pointer to the mutex and just because it is
half-finished and a subsequent mutex lock-and-unlock in another thread succeeds
this doesn't mean the call must be done... only when the first mutex_unlock
call also returns is the mutex unused"...
and yet the spec very explicitly disagrees
(as I quoted from the man page, which I assume is taken from the spec).
Similarly for condition variables.
All this leads me to believe that it was likely the intent of the spec authors
to say that, in general,
it is legal and legitimate usage to destroy any lock-like object
as soon as it is released for the last time by another thread
(which is always *before* the releasing function literally returns in that
other thread).
So it is on that basis that I say I believe it may be the intent of the spec
that my usage is legal, contrary to your assertion.

If you are still sure this is not the case,
would you please elaborate on your reasoning?

Thanks.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.