From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 10 01:00:29 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 886C17A0 for ; Wed, 10 Jun 2015 01:00:29 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 332C11BB4 for ; Wed, 10 Jun 2015 01:00:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id t5A10RqK049398; Tue, 9 Jun 2015 21:00:27 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 09 Jun 2015 21:00:27 -0400 (EDT) Date: Tue, 9 Jun 2015 21:00:27 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: "Russell L. Carter" cc: freebsd-hackers@freebsd.org Subject: Re: umtx_lock and friends In-Reply-To: <55778A60.9090200@pinyon.org> Message-ID: References: <55777108.5020206@pinyon.org> <55778A60.9090200@pinyon.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 01:00:29 -0000 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 >>> #include >>> #include >>> #include >>> #include >>> >>> 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