Author:             Christian Werner
Tcl-Version:        9.1
State:              Withdrawn
Type:               Project
Created:            2025-10-13
Keywords:           Tcl,threads

Abstract

This TIP proposes to disallow a reentrant usage of Tcl_Mutex, e.g. to call it twice from the same thread without unlocking in between. The reason is that there are technical issues on all platforms. In addition, it is seen as bad design and there is no current use-case. This implies to mainly remove TIP 509 .

Context

The original TIP 509 was invented to improve POSIX signal handling in multi-threaded Tcl and later overcome by TIP 511 which solved POSIX signal handling without requiring mutex reform.

Rationale

Making all Tcl_Mutexes reentrant interacts bad with Tcl_Conditions since in order to successfully (legally) wait on a condition requires the associated mutex to be unlocked exactly before the condition is waited on and re-locked exactly afterwards. However, a deadlock is most likely due when the mutex was (reentrant) locked more than once. To overcome this situation additional code would be needed in the Tcl_Mutex lock and unlock operations as well as in the wait on condition operation to prevent from this potential deadlock situation. Effectively, more logic is needed around synchronization operations, i.e. it is not possible anymore on the theoretical ideal POSIX platform to just wrap the native APIs for the Tcl_Mutex and Tcl_Condition synchronization objects.

Moreover, currently there are zero places in the Tcl core which require Tcl_Mutexes to be reentrant, so this feature can be regarded as superfluous anyway.

Tcl_Mutex was always reentrant on the Windows platform. Nevertheless, the combination with the Tcl_Conditions on Windows also may cause dead locks. The current documentation recomments to use Tcl_Conditions and Tcl_Mutex together in the reentrant case, which is critical on all platforms.

Specifications

A reentrant call of Tcl_Mutex is undefined. If this case is detected by Tcl_Mutex with no extra cost, a panic may be initiated.

Alternatives

Should there be real demand in having reentrant mutexes in Tcl a better alternative would introduce a new type, e.g. Tcl_ReentrantMutex, which provides this feature and simultaneously prevents from the above mentioned potential deadlocks since it cannot be used for conditions.

In addition, the commands may return an error code and not void.

Withdraw comment

Thanks for the TIP and the great thinking.

2025-12-02 HaO: the biweekly telco result:

All issues with reentrant mutex are solved
a performance penalty should be analysed to be checked if relevant

Copyright

This document has been placed in the public domain.