Lower bound for the maximum level of ownership for recursive_mutex?

Question

Quoting [thread.mutex.recursive]:

A thread that owns a recursive_mutex object may acquire additional levels of ownership by calling lock() or try_lock() on that object. It is unspecified how many levels of ownership may be acquired by a single thread. If a thread has already acquired the maximum level of ownership for a recursive_mutex object, additional calls to try_lock() shall fail, and additional calls to lock() shall throw an exception of type system_error.

Is there a lower bound greater than 1 for the "maximum level of ownership"? What about recursive pthread mutexes?

Tuque

It's unspecified (as in, the standard doesn't mandate any particular value, and implementations don't have to document this). – Moleskin

That being said, it's basically about a reference counter, and there doesn't seem much reason (in most situations) for that to not be at least a 32bit int. So, for all intents and purposes, I'd consider that limit higher than you could ever practically need. – Moleskin

Great question though. The fact that it's not given a lower bound is probably a defect in the standard. – Gui

Answer 1

There is no lower limit specified in the standard. This is probably deliberate.

Older standards (C I think) did use to provide lower limits for things like this. The result was that people wrote coding standards which said you couldn't use more than these lower limits. For example: It was (and I think still is) implementation defined how many characters of an external symbol were significant when comparing for equality. So a_very_very_long_name_indeed_with_extra_padding and a_very_very_long_name_indeed_with_extra_paddingX might be treated as the same symbol. The minimum length was specified as 8, and coding standards were written specifying "maximum length of a external symbol is eight characters".

On the plausible lower bound for this value: I can easily imagine that the count might be bit-packed into some other field so that the whole thing can be updated atomically with a suitable instruction. As such, it might be a good deal less than 32 bits. (It only really needs to be large enough for the maximum call stack depths, so in a constrained environment, 31 might be good enough.)

Unscreened