umtx_lock and friends

[Daniel Eischen]

On Tue, 9 Jun 2015, Russell L. Carter wrote:

> Hi Daniel,
>
> On 06/09/15 16:57, Daniel Eischen wrote:
>> On Tue, 9 Jun 2015, Russell L. Carter wrote:
>> 
>>> Hi,
>>> 
>>> I'm investigating what the most lightweight inter-process mutex
>>> technique on FreeBSD and have been looking at the
>>> infrastructure in /usr/include/sys/umtx.h
>>> 
>>> However, my simple test program fails to link:
>>> 
>>> #include <stdio.h>
>>> #include <sys/types.h>
>>> #include <machine/atomic.h>
>>> #include <errno.h>
>>> #include <sys/umtx.h>
>>> 
>>> int main(int, char **)
>>> {
>>>    printf("Testing...");
>>>    struct umtx m;
>>>    umtx_init(&m);
>>>    u_long id=5;
>>>    umtx_lock(&m, id);
>>>    umtx_unlock(&m, id);
>>>    printf("Test done.");
>>>    return 0;
>>> }
>>> 
>>> produces the following:
>>> 
>>> tester.cpp:(.text+0x36): undefined reference to `_umtx_lock(umtx*)'
>>> tester.cpp:(.text+0x5f): undefined reference to `_umtx_unlock(umtx*)'
>>> 
>>> I've tried linking against a variety of suspects in /usr/lib but
>>> no luck.
>>> 
>>> go-lang uses _umtx_op but they make the syscall directly via asm,
>>> it seems.
>>> 
>>> I can build an inter-process mutex over semaphores but the umtx
>>> stuff looks perfect if I can get it to work.
>> 
>> I'm not sure you are really suppose to be using those directly.
>> They are provided for FreeBSD's libraries (libthr) to use.
>
> But libthr doesn't support inter-process mutexes, correct?  Here's
> the relevant excerpt from pthread_rwlockattr_setpshared(3):
>
> "BUGS
>     The PTHREAD_PROCESS_SHARED attribute is not supported."

Correct, not supported yet.  A rather large change to change
pthread mutex and CV types from pointers to structs is needed.

>> If they are meant for public consumption, I don't like how they
>> are implemented as static inlines in sys/umtx.h - it's not
>> possible to properly bind to these functions from non-C
>> languages.
>> 
>> But, nonetheless, your example compiles and runs just fine as
>> a C program on FreeBSD 10-stable.
>> 
>
> On FreeBSD 10-stable r283752 amd64, here is the compile line:
>
> /usr/bin/cc -O -Wall tester.cpp -o tester
> /tmp/tester-b681b3.o: In function `main':
> tester.cpp:(.text+0x35): undefined reference to `_umtx_lock(umtx*)'
> tester.cpp:(.text+0x5c): undefined reference to `_umtx_unlock(umtx*)'
>
> Compilers don't matter, linking against libthr or libstdthreads
> doesn't matter.

Is cc doing something special because it thinks it is C++?
I'm on 10-stable amd64 and that example (saved as tester.c)
works just fine.

-- 
DE