From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24893 invoked by alias); 25 Nov 2016 12:04:22 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 24870 invoked by uid 89); 25 Nov 2016 12:04:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:2148, H*f:sk:cd280e3, H*i:sk:cd280e3, pay X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Nov 2016 12:04:20 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9E365AD7; Fri, 25 Nov 2016 04:04:18 -0800 (PST) Received: from [10.2.206.52] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2DA293F220; Fri, 25 Nov 2016 04:04:18 -0800 (PST) Subject: Re: [PATCH, newlib] Allow locking routine to be retargeted To: Sebastian Huber , newlib@sourceware.org References: <1478792031.1254.1.camel@op.pl> <60acaa10-fb22-8655-fd67-0536fe359871@foss.arm.com> <1478809956.1322.1.camel@gmail.com> <707976084.18201.1478865372907.JavaMail.zimbra@embedded-brains.de> <7dc33ad1-fecf-a0ec-81b6-2db698c5c57d@foss.arm.com> <58369A4A.8000907@embedded-brains.de> From: Thomas Preudhomme Message-ID: <0860238c-628a-8af9-5135-cf0cb84cbe30@foss.arm.com> Date: Fri, 25 Nov 2016 12:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016/txt/msg01131.txt.bz2 On 25/11/16 10:21, Thomas Preudhomme wrote: > > > On 24/11/16 07:44, Sebastian Huber wrote: >> Hello Thomas, >> >> On 23/11/16 15:38, Thomas Preudhomme wrote: >>> Hi Sebastian, >>> >>> I was thinking on how to solve this issue and found two possible solutions: >>> >>> 1) select size of lock at configure time >>> >>> Instead of being an enable/disable option the configure option could take an >>> integer value N that determine the size of lock, default being the size of a >>> pointer. The lock would then be defined as an array of N integers. >>> >>> Pro: LOCK_INIT works, simpler & smaller change >>> Cons: lock needs to be as big as the biggest lock among all the platforms you >>> want to target wasting a bit of space. >>> >>> 2) Remove static initialization of locks >>> >>> Remove all LOCK_INIT and add code as required to call lock_initialize at start >>> up time. >>> >>> Pro: you only pay the size for the lock you need (ie nothing except empty >>> functions in the single threaded case) >>> Cons: much bigger work, start up cannot support multithread >> >> 3) >> >> struct _lock; >> >> typedef struct _lock *_LOCK_T; >> >> #define __LOCK_INIT(class, lock) extern struct _lock _lock_ ## lock; class >> _LOCK_T lock = &_lock_ ## lock; >> >> The OS must then provide struct _lock and storage for all statically initialized >> locks. > > Oh nice, clever. I've check whether there is name collision in the source where > this would lead them to use the same lock and found: > > newlib/libc/sys/linux/iconv/gconv_db.c: __LOCK_INIT(static, lock); > newlib/libc/sys/linux/iconv/gconv_trans.c: __LOCK_INIT(static, lock); > > The one thing I worry is the risk of new lock being added with the same name. > Fortunately this could be detected at link time by looking for relocation to > "_lock_.*" in newlib library and check that there is no duplicate. One issue though, this means the OS needs to be updated each time a statically initialized lock is added to newlib. That seems to be a bit too much coupling. Or am I misunderstanding how this should be used? Best regards, Thomas