Mutex lock implementation

[vfj]

I am trying to instrument a rust binary to measure the hold and wait times for locks. I have a simple example with a single lock, but when I run the nm test-rs | grep pthread, I get the following output:

                 U pthread_attr_destroy@GLIBC_2.2.5
                 U pthread_attr_getguardsize@GLIBC_2.34
                 U pthread_attr_getstack@GLIBC_2.34
                 U pthread_attr_init@GLIBC_2.2.5
                 U pthread_attr_setstacksize@GLIBC_2.34
                 U pthread_create@GLIBC_2.34
                 U pthread_detach@GLIBC_2.34
                 U pthread_getattr_np@GLIBC_2.32
                 U pthread_getspecific@GLIBC_2.34
                 U pthread_key_create@GLIBC_2.34
                 U pthread_key_delete@GLIBC_2.34
                 U pthread_self@GLIBC_2.2.5
                 U pthread_setname_np@GLIBC_2.34
                 U pthread_setspecific@GLIBC_2.34

As you see, it doesn't use the pthread_lock and pthread_unlock. Could you please help me with this issue?

[carey]

The Rust standard library builds its on locks on top of OS primitives; for Linux, on top of futexes. You can see part of this in rust/futex_rwlock.rs at master · rust-lang/rust · GitHub, which uses inlined operations on two AtomicU32 fields to implement the lock.

Since an uncontended lock operation is only a memory access, I'm afraid tracking locks won't be as simple as tracking function calls or syscalls.

[cuviper]

@carey

The Rust standard library builds its on locks on top of OS primitives; for Linux, on top of futexes.

That was done in Rust 1.62.0. So if you really want pthread mutexes, you could use Rust 1.61 or earlier, but that won't be a long-term solution...

[kornel]

Note that many Rust crates also use parking_lot, which has its own locking mechanism, not using pthreads.