From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56123 invoked by alias); 11 Nov 2016 09:38:20 -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 56011 invoked by uid 89); 11 Nov 2016 09:38:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,MISSING_MIMEOLE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=implications, Hx-languages-length:1607, Von, HImportance:normal X-HELO: mailout10.t-online.de Received: from mailout10.t-online.de (HELO mailout10.t-online.de) (194.25.134.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Nov 2016 09:38:09 +0000 Received: from fwd27.aul.t-online.de (fwd27.aul.t-online.de [172.20.26.132]) by mailout10.t-online.de (Postfix) with SMTP id 5EF4741EE14F for ; Fri, 11 Nov 2016 10:38:06 +0100 (CET) Received: from spica08.aul.t-online.de (VODJb-ZC8hM3oEBm5nxM5+Q7Eq38WA0FjsO9r8RNejILqKEvaLiAxAi9p23Dkd1gAo@[172.20.102.122]) by fwd27.aul.t-online.de with esmtp id 1c58HX-1z4D560; Fri, 11 Nov 2016 10:37:59 +0100 Received: from 93.236.161.245:11996 by cmpweb28.aul.t-online.de with HTTP/1.1 (Lisa V4-5-4-0.13657 on API V5-2-0-0) Received: from 172.20.102.137:38818 by spica08.aul.t-online.de:8080; Fri, 11 Nov 2016 10:37:59 +0100 (MET) Date: Fri, 11 Nov 2016 09:38:00 -0000 From: "onkel.jack@t-online.de" Reply-To: "onkel.jack@t-online.de" To: newlib mailing list Message-ID: <1478857079349.2887660.49b88d9bb7d34cdf62b9a6093a7319fdaa3e129c@spica.telekom.de> In-Reply-To: <1478810097.1322.3.camel@op.pl> References: <1478792031.1254.1.camel@op.pl> <60acaa10-fb22-8655-fd67-0536fe359871@foss.arm.com> <1478809956.1322.1.camel@gmail.com> <1478810097.1322.3.camel@op.pl> Subject: AW: [PATCH, newlib] Allow locking routine to be retargeted MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016/txt/msg01087.txt.bz2 Hello, to unconditionally provide weak dummy implementation I dont think its a goo= d idea since it has some implications: If the newlib is compiled for single thread, no locks are required at all, = so the dummy implementation/macro is doing the job to satisfy the linker. But for multithread its dangerous to provide a dummy since you would not se= e first hand there are no locks but dummys. So my suggestion would be: - For single thread leave the implementation as is. - For multithread, dont provide any lock function, so linking newlib withou= t to provide locking functions from os/kernel=20 would result in a linkage error, therefore forces the user not to forget to= provide them. So I think, just put something like #ifndef MULTI_THREAD around the existin= g macros would do it.=20 -----Original-Nachricht----- Betreff: Re: [PATCH, newlib] Allow locking routine to be retargeted Datum: 2016-11-10T21:35:30+0100 Von: "Freddie Chopin" An: "newlib@sourceware.org" On Thu, 2016-11-10 at 21:32 +0100, Freddie Chopin wrote: > void __lock_acquire(_LOCK_T lock) > { > if (lock =3D=3D 0) > { > // lock not yet really initialized... > disableInterrupts(); > if (lock =3D=3D 0) // re-check due to possible race > condition > lock =3D malloc(sizeof(RealMutexFromYourRtos)); >=20 > assert(lock !=3D 0); > rtos_mutex_create(lock); > enableInterrupts(); > } >=20 > rtos_mutex_lock((RealMutexFromYourRtos*)lock); > } I've obviously missed some curly braces for the inner "if", but I guess you get my idea anyway (; Regards, FCh =EF=BB=BF