[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 26 Feb 2022 12:38:55 +0100
From: Joakim Sindholt <opensource@...sha.com>
To: musl@...ts.openwall.com
Subject: Re: Suggestion for thread safety
On Sat, 26 Feb 2022 09:56:04 +0000, Lee Shallis <gb2985@...il.com> wrote:
> On Wed, 23 Feb 2022 at 18:58, Markus Wichmann <nullplan@....net> wrote:
> >
> > 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.
> >
> There are no bugs, I made sure to test this after all, I deliberately
> created a situation where any bugs would show them selves, the only
> thing that was a potential problem I've now fixed (after doing some
> research to find out if 0 is ever a valid thread id), the concept
> remains the same, just with support for developer calling LockSiData
> twice:
Did I use it wrong then?
zhasha@...belwind /home/zhasha ; gcc -lpthread buglock.c
zhasha@...belwind /home/zhasha ; ./a.out
var = 1, expected 0
zhasha@...belwind /home/zhasha ; ./a.out
var = 1, expected 0
zhasha@...belwind /home/zhasha ; ./a.out
var = 2, expected 1
zhasha@...belwind /home/zhasha ; ./a.out
var = 2, expected 1
var = 1, expected 0
zhasha@...belwind /home/zhasha ; ./a.out
var = 1, expected 0
View attachment "buglock.c" of type "text/plain" (1271 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
