Not sure this is the best group: my question concerns the actual 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.ka...@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
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?
> 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.)
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. Please read the fifth and fourth paragraphs, respectively, of the DESCRIPTION sections of the following two pages:
On Jul 4, 12:41 pm, David Schwartz <dav...@webmaster.com> wrote:
> 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 (GABI Software) email:james.ka...@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
On Jul 4, 10:32 pm, Philip Guenther <guent...@gmail.com> wrote:
> 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.
On Jul 5, 3:56 am, James Kanze <james.ka...@gmail.com> wrote:
> > 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.
On Jul 5, 4:01 am, James Kanze <james.ka...@gmail.com> wrote:
> 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.
|
