From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116102 invoked by alias); 25 Nov 2016 12:35:41 -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 116049 invoked by uid 89); 25 Nov 2016 12:35:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.9 required=5.0 tests=AWL,BAYES_00,FOREIGN_BODY,RCVD_IN_DNSWL_NONE,SPF_PASS,T_FILL_THIS_FORM_SHORT autolearn=no version=3.3.2 spammy=diese, Nachricht, nachricht, 4116 X-HELO: dedi548.your-server.de Received: from dedi548.your-server.de (HELO dedi548.your-server.de) (85.10.215.148) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Nov 2016 12:35:30 +0000 Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1cAFix-00083Z-Ny; Fri, 25 Nov 2016 13:35:27 +0100 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cAFix-0005I2-2Q; Fri, 25 Nov 2016 13:35:27 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 92D9A2A01AE; Fri, 25 Nov 2016 13:35:31 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id IlpZK--GAgnL; Fri, 25 Nov 2016 13:35:31 +0100 (CET) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 130E02A180C; Fri, 25 Nov 2016 13:35:31 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TBo009waV65m; Fri, 25 Nov 2016 13:35:30 +0100 (CET) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id E62D52A01AE; Fri, 25 Nov 2016 13:35:30 +0100 (CET) Subject: Re: [PATCH, newlib] Allow locking routine to be retargeted To: Thomas Preudhomme , 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> <0860238c-628a-8af9-5135-cf0cb84cbe30@foss.arm.com> From: Sebastian Huber Message-ID: <5838300D.6090000@embedded-brains.de> Date: Fri, 25 Nov 2016 12:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <0860238c-628a-8af9-5135-cf0cb84cbe30@foss.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016/txt/msg01132.txt.bz2 On 25/11/16 13:04, Thomas Preudhomme wrote: > > > 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=20 >>>> solutions: >>>> >>>> 1) select size of lock at configure time >>>> >>>> Instead of being an enable/disable option the configure option=20 >>>> could take an >>>> integer value N that determine the size of lock, default being the=20 >>>> 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=20 >>>> 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=20 >>>> lock_initialize at start >>>> up time. >>>> >>>> Pro: you only pay the size for the lock you need (ie nothing except=20 >>>> 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;=20 >>> class >>> _LOCK_T lock =3D &_lock_ ## lock; >>> >>> The OS must then provide struct _lock and storage for all statically=20 >>> initialized >>> locks. >> >> Oh nice, clever. I've check whether there is name collision in the=20 >> 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=20 >> same name. >> Fortunately this could be detected at link time by looking for=20 >> 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=20 > statically initialized lock is added to newlib. That seems to be a bit=20 > too much coupling. Or am I misunderstanding how this should be used? Yes, but how many locks per minute are added to Newlib? --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG.