«

On 2012-10-01, Keith Thompson <kst-> wrote:
> So what does mtx_destroy() do if some thread *is* blocked waiting
> for mtx?

What if some thread is using a pointer P and another one calls free(P)?

The program is broken in that situation. One thread is finalizing an object,
but it has no right to do that because the object is referenced elsewhere.

The real POSIX API provides return values for situations like this: EBUSY (the
mutex is being destroyed while it is locked or in use) and EINVAL: the mutex is
invalid.

However, these return values are optional! Implementations do not have check
these situations. (Not even for mutexes attributed as having type
PTHREAD_MUTEX_ERRORCHECK: that type causes certain very specific debugging
checks to be required in the lock and unlock operations only.)

Am 30.09.2012 23:13, schrieb Markus Elfring:
>> There is already an implementation of C11 threads as a wrapper around
>> POSIX threads that is publicly available.
>
> I would interpret source code like the following as an update candidate.
>
> http://p99.gforge.inria.fr/p99-html/...8h_source.html :
> ...
> 00633 // 7.26.4 Mutex functions
> 00634
> 00638 p99_inline
> 00639 void mtx_destroy(mtx_t *p00_mtx) {
> 00640 (void)pthread_mutex_destroy(&P99_ENCP(p00_mtx));
> 00641 }
> ...
>
>
> How do think about to get rid of the cast to the return type "void" in such use
> cases?

Ok, the discussion that followed this have conviced me that we are
facing a defect of the C11 specification here. I have written up my
ideas about that and added the report to my list on

http://p99.gforge.inria.fr/defects-and-improvements

Jens

> The main difference is really the starting point of this discussion,
> the differing function types for threads. And this one is well
> justified from the POV of C, int is the type that you'd have
> to expect as a return from a thread, just as main returns an int
> to the environment.
>
> On my page for possible defects/improvements for C

I am curious if you will get feedback by standardisation committee members for
your descriptions.
http://p99.gforge.inria.fr/defects-a...functions.html

Did you forward any of them to an "official" communication channel?


Do the discussed functions just use an interface style that we all know from a
function like "free"?
http://pubs.opengroup.org/onlinepubs...ions/free.html

Do such standard specifications allow different error handling implementations?

Regards,
Markus

Markus Elfring <> writes:
>> The main difference is really the starting point of this discussion,
>> the differing function types for threads. And this one is well
>> justified from the POV of C, int is the type that you'd have
>> to expect as a return from a thread, just as main returns an int
>> to the environment.
>>
>> On my page for possible defects/improvements for C
>
> I am curious if you will get feedback by standardisation committee
> members for your descriptions.
> http://p99.gforge.inria.fr/defects-a...functions.html
>
> Did you forward any of them to an "official" communication channel?
[...]

Posting to comp.std.c is *slightly* more likely to get the committee's
attention than posting to comp.lang.c. The committee has no official
relationship with either newsgroup, but comp.std.c has lower traffic and
is likely to have more commmittee members reading it.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Hello,

Am 03.10.2012 11:02, schrieb Markus Elfring:
>> The main difference is really the starting point of this discussion,
>> the differing function types for threads. And this one is well
>> justified from the POV of C, int is the type that you'd have
>> to expect as a return from a thread, just as main returns an int
>> to the environment.
>>
>> On my page for possible defects/improvements for C
>
> I am curious if you will get feedback by standardisation committee members for
> your descriptions.
> http://p99.gforge.inria.fr/defects-a...functions.html
>
> Did you forward any of them to an "official" communication channel?

I am not sure what channel that would be, the ISO committees don't
seem to be very open to the outside world. But as Keith suggest,
comp.std.c has probably better chances to be read, so I am
crossposting there.

> Do the discussed functions just use an interface style that we all know from a
> function like "free"?
> http://pubs.opengroup.org/onlinepubs...ions/free.html
>
> Do such standard specifications allow different error handling implementations?

Yes, I think so. It clearly defines under what circumstances the
behavior is undefined, so an implementation would be allowed to define
a behavior as it wishes in these cases.

Generally, if you look at the text for free that you are citing, and
compare it with the text about the threads in C11, you'll notice a
difference in quality. C11 certainly lacked some iterations of
discussion and error correction before it went into the standard. In
particular, a better coordination with the POSIX committee would have
been in order concerning threads.

Jens

>> I am curious if you will get feedback by standardisation committee members
>> for your descriptions.
>> http://p99.gforge.inria.fr/defects-a...functions.html
>>
>> Did you forward any of them to an "official" communication channel?
>
> I am not sure what channel that would be, the ISO committees
> don't seem to be very open to the outside world.

Do you get also any useful information by Derek M. Jones occasionally?
http://www.knosof.co.uk/cbook/


> Generally, if you look at the text for free that you are citing,
> and compare it with the text about the threads in C11, you'll notice
> a difference in quality. C11 certainly lacked some iterations
> of discussion and error correction before it went into the standard.
> In particular, a better coordination with the POSIX committee
> would have been in order concerning threads.

I see also another update candidate if you compare descriptions for the
functions "pthread_cond_wait" and "cnd_wait".

http://pubs.opengroup.org/onlinepubs...cond_wait.html :
"...
When using condition variables there is always a Boolean predicate involving
shared variables associated with each condition wait that is true if the thread
should proceed. Spurious wakeups from the pthread_cond_timedwait() or
pthread_cond_wait() functions may occur.
Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not
imply anything about the value of this predicate, the predicate should be
re-evaluated upon such return.
...."

How do you think about further clarification for the handling of "predicates"
and "spurious wakeups" by the current standard specification for the C
programming language?
Do you need not to care for them eventually because they are not mentioned in a
corresponding draft document?
http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf

Regards,
Markus

On 10/1/2012 18:19, Keith Thompson wrote:
>
> I haven't studied C11's <threads.h> closely, but I do find the
> description of mtx_destroy() a bit troubling:
>
> Synopsis
>
> 1 #include <threads.h>
> void mtx_destroy(mtx_t *mtx);
>
> Description
>
> 2 The mtx_destroy function releases any resources used by the mutex
> pointed to by mtx. No threads can be blocked waiting for the
> mutex pointed to by mtx.
>
> Returns
>
> 3 The mtx_destroy function returns no value.
>
> So what does mtx_destroy() do if some thread *is* blocked waiting
> for mtx? I suppose the behavior is undefined by omission, but
> changing the word "can" to "shall" would have made that explicit.
>
> And why not define the behavior, more or less as POSIX does?
> Would detecting blocked threads be too difficult on some systems?
>

Maybe the function waits for such threads to unblock, before it releases
the resources. (Just kidding.)

- Shao Miller

On 10/1/2012 17:58, Keith Thompson wrote:
>
> An enumeration type (without a tag or typedef) is an easy way to
> achieve that. Adding a tag and/or typedef would create a type name
> that's never actually used. Using that type for the parameters to
> the relevant functions would not provide any type safety.
>

Other than IDEs which show the possible named enum values while you're
typing an argument or such.

- Shao Miller