| In CMA, all of the "object types" are handles, and can be copied freely.
(That doesn't necessarily mean it's a good idea, but you're allowed to, and
it'll always work.) So, yes, you can copy a cma_t_mutex, have one thread lock
the first and another lock the second, and they are guaranteed to be using
the same mutex. Similarly for condition variables, atomic queues, attributes,
etc.
Digital's implementation of POSIX 1003.4a/D4 (DCE threads) was designed on
top of the CMA "engine", and the DCE thread types (pthread_t,
pthread_mutex_t, etc.) were actually CMA handles. Thus, you could get away
with the same sort of behavior. HOWEVER, the POSIX draft standard did not
guarantee this, and vendors shipping DCE implementations were not required to
use our "reference code", and thus any such assumptions were nonportable.
Because of the way the draft standard was specified, it was safe to copy
thread identifiers (pthread_t) and attributes objects (pthread_*attr_t),
because the interface passed them by value already (essentially a copy
operation).
POSIX 1003.1c-1995 does not allow copying of any object -- mutex, condition
variable, attributes object. However, pthread_t isn't an "object", it's a
reference to an object -- and is required to be copyable for the interface to
work (it's passed by value -- copied -- to pthread_join, etc.)
IF you were to copy a pthread_mutex_t, for example, you hypothesized that
this might act as a different mutex. It's actually worse -- there's no
guarantee that the copy will even BE a mutex. Using it might not work, or
might break code using the original mutex. In standardese, the results of
using a copy of a synchronization object are "undefined". Error, incorrect
synchronization, program hang, system crash, earthquake, solar eclipse,
supernova, galactic black hole... you just don't know.
So protect the universe -- don't do it!
/dave
|
| Thanks!
>IF you were to copy a pthread_mutex_t, for example, you hypothesized that
>this might act as a different mutex.
I did? Wow. :-) That certainly made me go back and reread my
note!
> does b.mutex refer to the same mutex as a.mutex? If one
> thread locks a.mutex will a second thread block if it tries to
> lock b.mutex?
Aha...the implicit alternative could be that b.mutex refers to
a different mutex. I was thinking more along the lines of the
alternative being to RAISE(cma_e_existence) because DECthreads
didn't recognize &b.mutex as being the address of anything it
knew about.
>supernova, galactic black hole... you just don't know.
I had thought that only violations of the ANSI C standard
could do that, but I guess other standard writers hold that
power as well. :-)
Dan
|
| A quicky follow-up ... under any of the DECthreads interfaces,
is there ever a problem letting a local variable of a created
object "go out of scope" without having destroyed the object?
For example, after
{
cma_t_attr attr;
cma_attr_create(&attr, &cma_c_null);
} /* no call to cma_attr_delete */
or
{
pthread_attr_t attr;
int status = pthread_attr_init(&attr);
if (status != 0) { /* error handling ... */ }
} /* no call to pthread_attr_destroy */
will later re-use of the stack location occupied by "attr"
corrupt DECthreads, or is this "merely" an otherwise "safe"
resource leak?
Dan
|
| To emphasize the secondary aspect of Webb's reply, it definitely MAY leak
memory. And that can lead to other application problems.
If you create/init an object, you must destroy it, not simply allow it to go
out of scope. Failing to do so is an error. The exception is that statically
initialized mutexes and condition variables (declared with
PTHREAD_MUTEX_INITIALIZER or PTHREAD_COND_INITIALIZER) need not be destroyed,
although it's a good idea to do so if you know you won't use them anymore.
/dave
|