copying pthread_mutex_t, pthread_cond_t
James Kanze
Posix standard, and what it says.
Basically, is it legal to copy a pthread_mutex_t or a
pthread_cond_t, and use the copy? If not (which is the only
answer which makes sense to me), where does the Posix
specification say this? If so, what does it mean: what happens,
for example, if a copy a mutex which is held by a thread, wait
on the copy, and the holding thread frees the original?
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
David Schwartz
> Basically, is it legal to copy a pthread_mutex_t or a
> pthread_cond_t, and use the copy?
No. The reason is simple -- that is semantically ambiguous. Does the
copy refer to the mutex, simply copying the reference to it? Or does
it refer to a new mutex initialized to the same state as the original
mutex? If the mutex copied is locked, is the copy locked?
> If not (which is the only
> answer which makes sense to me), where does the Posix
> specification say this?
Where does the POSIX specification say you can't add one to a
pthread_mutex_t? The standard does not have to explicitly prohibit
every crazy thing you can imagine to do.
> If so, what does it mean: what happens,
> for example, if a copy a mutex which is held by a thread, wait
> on the copy, and the holding thread frees the original?
The standard doesn't say. So, anything can happen. (Or, if it does, I
couldn't find where.)
DS
Philip Guenther
> pthread_cond_t, and use the copy?
A program that does that invokes undefined behavior.
> If not (which is the only answer which makes sense to
> me), where does the Posix specification say this?
You know, you really ought to get your computer fixed so that you can
download your own copy of the standard or access the online copy.
Please read the fifth and fourth paragraphs, respectively, of the
DESCRIPTION sections of the following two pages:
http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_destroy.html
http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_destroy.html
I don't understand why David makes claims about what the standard says
or doesn't say which are not true.
Philip Guenther
James Kanze
> On Jul 4, 2:50 am, James Kanze <james.ka...@gmail.com> wrote:
> > Basically, is it legal to copy a pthread_mutex_t or a
> > pthread_cond_t, and use the copy?
> No. The reason is simple -- that is semantically ambiguous.
> Does the copy refer to the mutex, simply copying the reference
> to it? Or does it refer to a new mutex initialized to the same
> state as the original mutex? If the mutex copied is locked, is
> the copy locked?
Exactly. That's part of my question.
> > If not (which is the only
> > answer which makes sense to me), where does the Posix
> > specification say this?
> Where does the POSIX specification say you can't add one to a
> pthread_mutex_t?
The fact that it doesn't guarantee that the type is an integral
type. This doesn't hold for copying, because C supports copying
any data type.
> The standard does not have to explicitly prohibit every crazy
> thing you can imagine to do.
That's what standards are supposed to do. By saying that the
type pthread_mutex_t is transparent, or unspecified, the
specification effectively says that you can't do anything with
it except take its address or copy it. If you can't copy it,
the standard should effectively says so. (It does, for example,
for FILE.)
James Kanze
> On Jul 4, 2:50 am, James Kanze <james.ka...@gmail.com> wrote:
> > Basically, is it legal to copy a pthread_mutex_t or a
> > pthread_cond_t, and use the copy?
> A program that does that invokes undefined behavior.
> > If not (which is the only answer which makes sense to
> > me), where does the Posix specification say this?
> You know, you really ought to get your computer fixed so that
> you can download your own copy of the standard or access the
> online copy.
Or learn to read more carefully. The only problem with my
computer is the nut between the keyboard and the chair.
> Please read the fifth and fourth paragraphs, respectively, of
> the DESCRIPTION sections of the following two pages:
> http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mute...
> http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_cond...
The worst it that I actually opened these two pages; I don't
know how I missed the relevant paragraph, since it is extremely
clear and immediate.
David Schwartz
> > Where does the POSIX specification say you can't add one to a
> > pthread_mutex_t?
> The fact that it doesn't guarantee that the type is an integral
> type. This doesn't hold for copying, because C supports copying
> any data type.
This is a distinction without a difference. Yes, in one case the
standard guarantees it's possible to do and in the other it doesn't.
But both are obviously idiotic and have no sensible purpose or clear
meaning. The standard doesn't have to prohibit either.
> > The standard does not have to explicitly prohibit every crazy
> > thing you can imagine to do.
> That's what standards are supposed to do.
No, not at all. Standards are supposed to tell you what you can do and
permit you to rely on getting the specified results when you do.
However, there are an unlimited number of things you can't do and
there is simply no way a standard can list them all.
> By saying that the
> type pthread_mutex_t is transparent, or unspecified, the
> specification effectively says that you can't do anything with
> it except take its address or copy it. If you can't copy it,
> the standard should effectively says so. (It does, for example,
> for FILE.)
It is sufficient that there be no sensible way to determine what
effect a particular operation should have. There is no need for the
standard to explicitly prohibit it. The standard doesn't have to say
something is undefined or unspecified -- if it doesn't define it, it's
undefined; if it doesn't specify it, it's unspecified.
DS
David Schwartz
> The worst it that I actually opened these two pages; I don't
> know how I missed the relevant paragraph, since it is extremely
> clear and immediate.
Same here. But in any event, the result would be precisely the same if
it didn't say that. Not defining something leaves it undefined just as
much as saying it's undefined does.
DS