From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16180 invoked from network); 23 Feb 2022 18:58:02 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Feb 2022 18:58:02 -0000 Received: (qmail 19487 invoked by uid 550); 23 Feb 2022 18:57:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18419 invoked from network); 23 Feb 2022 18:57:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1645642667; bh=G0my+cGQcSUz/dYNfIYZXVGCzrtQzFskjUp0PitTyy8=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=RHfmsC2KxtnrlICJ+4eovvGOkIT9dhZRU/40+cR8YqI6g0d2dML7zUTRO5CnJrBp4 xFWSCk911+gIt3A5T3zHVxVI1xRoCn2vWkYJ1wN5or9EPb0iTejDwqZOfYYsxf4RMr 0RyiB97Wv9h9STpY74lhIlMQy9nYBQU9BZDcDrSE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Wed, 23 Feb 2022 19:57:46 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220223185746.GB2079@voyager> References: <20220221174223.GA2079@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:sTTBTxdaPB0YbeL/blNvKMogLvYVuDHPUUNamvo7E0NkRTTSeh7 /u/QQvPU2RLpKjJxKwdlq+3wOqEq2qPlXI695rWk83vfWzs3rJ1f1dexdRDGh4Jr0mm4pzq g0zgsl2WVzmc3ugAyxagNLmIXEg8x+WLLvNrOwTavaSGnpz8R3HBklmYO9Wp73h8k1iKdLV A/zsm27wr9GQ7ZRrxfQpQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:0L9oyCd6H74=:bTeIe/tzXgB2R/Gc4/8X1V 6BUOQd0WQBKyN75SOCAJXACcOksxfcAvJiOOIFw7MS+/K+okRb50xlTBzsC9SCCxjD3T5LWzh /oBG27A+N5lH/KByzIaQ4ltGjr79iDlcIXVUAh3V7r42jaomEcaWQDhqU9Y73pj0aRc+wTvLP zUbSZhLyAS3hn7vvpuD37ZR677Y54Khb4CW1sa6NmRWs/PqtUfoYROZ6Tf8O0TqbzRVgMXEAE aZKGyVdhJl34CtWO5YVwvkd6+ALfmWuh7VIDqgVr3CHpNhEmdP3b5czSgz/3gNetocGuYJcY+ DBnUEXqF1FeoMyE4F/GJHt1aqVwfYS/xUB03LqG8j7wRH7Ode8xBS4GhLFhH2xbuVGaOwmatw 9M3piqjjUJoX8PwxXpw6DnWzCQGHATPaC1zd5fWDQbfaPqftdDir94DngDksjy6asNuonVyej FLGlYjxbheKjUhaQJVlu8i8vQg07WL5zCZK+Qe7sZjxY/iKsb4vWSF3grMitpkNd3AAwlxL4S CeN1Z3YvxCnhkLp/NB5hevSi18GOciTWF6NHVYDC2dCINuPmbe24QUOZjeNcI4dToEZ+O4XTc fLKamDe8PW1q/+d5FC1wTvh0lEgD2l57dnhXSY2B4V9sFVfrq8+q3pvSrG0hSj3IUc/6w/67N /rY82dktQVmJoG8PETTjx4iv5ZCJpLq5ujbnVmg+y9500KhVfb/lhj/7vs0ynDCSuTWTFj7jb btSRtIS+3Lmnbu+zChQ1DtjOSEFPCbDb4Izb5Ju8vJF1aZd9+lhyMt4e/unDngg1SeC/yMyMp NLbUb4om7hTkTmWc6vAkGyOncz9LNRyXYsWCyLA2wVBOs/iKPp0+DJ7gb1e0AYKoFv0QLsTnH gMzYH1NwB9PkdQSBDK9tuFi4FplLulzL43+oKp9R6YtUc94Q8yZhrdUSFfwCc93+bquoR5EV3 vflSsk4cyc5CgU6LoV/ZYuabeDxSFPc6ltXYXr85QRnBHr1Puo4Nzjq0H3QpNhtAWKo+uN1WG lJDcvTfMuJjCD/z1unuI3gnSym1HVWxk4JtPcL2pRE/XlVoPp2ElxQfegjr/3g2wZdO1h+jCP G2MuqoLdD5odyo= Subject: Re: [musl] Suggestion for thread safety On Wed, Feb 23, 2022 at 12:30:43AM +0000, Lee Shallis wrote: > think of the lock as the same as a mutex, just simpler, It isn't really simpler than a fast mutex, but a lot buggier. > it is supposed > to prevent execution races for potentially non-thread safe system > calls such a poorly implemented malloc (which can have it's symbol > overwritten by a developer implementation), Any malloc implementation has to be thread safe. It is not sensible to use one that isn't. It is also not sensible to pessimise the whole program because one day a developer might choose to do something stupid. > fprintf etc (which from > what I've heard are NOT thread safe) fprintf() takes a FILE and must therefore act as if flockfile() was called on entry and funlockfile() on exit. IOW: Accesses to the same file are ordered. If not, the implementation is broken. > also errno might not be > thread local under some implementations, Any such implementation is fundamentally broken and cannot be repaired. There is no way to call a blocking system call in such a system without taking the lock on errno first, thereby suspending all other threads that might try to access errno, which is pretty much all of them, except maybe for some pure calculations somewhere, thereby negating any benefit multi-threading might have brought the program. > it's better to assume it's > not then to assume it is and have all hell break loose. I disagree. It is better to assume the standards are followed and fix problems as they occur than to assume you are programming for some kind of space alien computer that works by rules inconsistent with any normal system. Report the bug, work around it if necessary, and move on. I recently found myself on a system on which, unbeknownst to me, sendmsg() always returns 0 when called on TCP sockets. I wrote a program assuming it would work. It did not. I reported the bug and worked around the problem with malloc() and send(). That is why we test. > just use it to simplify any code that had to go through the > effort of calling pthread_mutex_create/pthread_mutex_destroy or > whatever, PTHREAD_MUTEX_INITIALIZER exists. > the code I gave was literally a simple > example of how to hide system thread safety details in pure ansi C, Nonsense. You didn't hide anything, you didn't make anything safer, and by staying in ANSI C, you make it impossible to achieve your goal. > As for your point about splitting paragraphs up, I'm not very good at > that as you might have noticed by now, If you don't care to be understood, I won't care to understand you. And it is pretty difficult to convince people that don't understand you. > anyways the point of these is > that I wanted a simpler system than the one that is provided so that > if I ever put enough work into my library that it no longer needs libc > then I would be able to do so rather seamlessly, You might have bitten off more than you can chew with that goal. Writing a libc is no mean feat, and developing a library to the point it could replace libc takes about as much effort. Somehow people seem to think they'll start with memcpy() and it will stay on that level of complexity. It won't. > in other words just > with LOCK & pauseCB I've achieved thread safety without the file > knowing anything about the system api, You have indeed not done that. You have instead written the word "lock" enough times to give someone skim-reading the file false confidence that this stuff will actually work in a multi-threaded context, only to then fail under high load for inexplicable reasons. I keep seeing this behavior from programmers that ought to know better. You see, an exclusive lock consists of two parts: The mutual exclusion and the sleep. And yes, spinlocks skip the second part, but my point is: The mutual exclusion is actually the easy part, and any hack with a Messiah complex and a CPU manual can do it. The sleep is the hard part, if you want to do it right. It needs to be Goldilocks. Too short, and you are wasting resources (every time your thread spins in the loop is time the CPU could have better spent on other threads), too long and you are wasting time. Your sleep is definitely too short, and you didn't even get the mutual exclusion part right. Ciao, Markus