From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by sourceware.org (Postfix) with ESMTPS id 45AA33858D28 for ; Mon, 21 Mar 2022 06:20:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 45AA33858D28 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.100.7] ([154.160.14.105]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N3bSj-1oFFPX06BX-010dWY; Mon, 21 Mar 2022 07:20:00 +0100 Subject: Re: rwlock different behavior on glibc 2.28 then on previous versions To: David Mozes , Florian Weimer Cc: "libc-help@sourceware.org" References: <87czis1tgk.fsf@oldenburg.str.redhat.com> From: Christian Hoff Message-ID: <8681b86f-963c-7c01-3d7a-9c4cb3da52c8@gmx.net> Date: Mon, 21 Mar 2022 07:19:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux armv7l; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB X-Provags-ID: V03:K1:NSPkgzGucHIuN+IuSyAPaTqDqhY94iNUJ0SoLJMT8ZkPM5J+Ddg 6kVOdFdv3AdaCwiP/SSLMw/RxUFAlojrtimD1Ugve3zSytX4NrNQllRIiVH/zrsrA0yUKHy jE6RoXMZtEYVhayXR8d73XsPQpUBMbGaex+oLDHFmleBZYQTfKVll5G4g/4oKe/B5wa1KtU U7BlpG89K2dOv0jqoUqcQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:25d78hTsoEY=:3Z1B8IZTSIdt2AklQ6/R+4 l49fGEDPQEVKDOAeYxNAYg2wIxcMXb5ZWFafcR15MCTaw2kpCyjjDQcrnNta2GRhKPTpRrEB7 azC+/xJHptRm7cXu3Z+heFLxKjbkq2eNxlH4G7ho17N0xPh13zIfffWy7Xwcj4MlgS+SvUe/B b7ac1A46SosBSH3296UwVQykJ9sZiEMWozXFlZxsLREcR2FBIes85AEQr1hoTlSyAJS++Wgoo ZiuzXhCjRDNgI0JS84WqNeEtWL6//7KjK+Zt9y3pCqy7G5KVnT9QR47S3y2qhYW0qSAVOlPOB KQ+jzPGgVUs/rHRdD6nudeZLiHdzwgycDUPqfMqdo07jKi4lyTjA7QKNLncpa6CHWfa8Yj2Ma uLP4AdvO8e8il85Ar8Z8LTHnKjX/MgZK2Di10DmRTUM8udiQqy5+Fmbfu8AtjksNbsMmqsKNh k4Qoo5epNaPLAxOW1Xc0wrcGTnqpuWIgAejZTWyxuX4Ge9VHjgKAb9cpFJb/MtZZL2D+EMq3O JuX/ZhWBLM5EWF+DxXZv+b9IW3TQTb9WEnn4z5B+uhbiUoASRk3LJneCt8x5+DDo1rZgRGL/y +T+hkduG7g/nDWb09xfvKyhhFCGFEndQ+/0WxHph3Lj/1RK1jwN1uF4UiBYaVzyZlSESQhoEM EWD/iNxnGUn3RcwLR+jEfVkdUNaGey3DXdWWwe3OXw9dlahNHbzquy74qRoQ1/+XaOXiDXOtz 5anPyTICK5UvCk3386PEOXAarn6jG0pkJrIrtEldUW3yL864tApLFJptt3Ug2cNQQObTN2+5y CEzSbSzqQKPlGaIeG/epA9bk6EicjF0Qi1pnZXGyqIvkk5V/R/aqU1AxlZ7a7hHYcU0d1QocS sAEBOJIu+c8GJClFkyXjB6wbSE/vuX/vdO6DtcnIgmlJI4l8Hif8K9lGwOYkvsEOp31AXT8rd V6UIRdOseCeykg5FCubUuJsz/T+gCeS4HxW2WVtYt8EVjxfVjjIj3eLlDDvfn9gQ2bAsbPIE3 I9SJ55Qu3+9ZVyYQZ+ntr3jmg18ExvNXJmw6e0ELqURObMorKFyEFxRhQFpmU0nN1EyWY9EFX NutlGW3VOhKlPg= X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 06:20:07 -0000 Hallo David, did you try to run your program with Helgrind already? Helgrind was designed to catch problems like this. Maybe Thread Sanitizer would also detect the issue. Best regards, =C2=A0=C2=A0 Christian On 3/20/22 5:44 PM, David Mozes wrote: > Hi, > Where are we with this? > Also, the current implementation of the __pthread_rwlock_unlock is prob= lematic. > On the one hand, it checks the API agreement. However, on the case of vi= olation, the user don't have any induction > And function return OK > See example code below: > > > struct threadInfo{ > pthread_t* tid; > pthread_rwlock_t *rwlock; > }; > > void *lockerThreadFunction(void *vargp) > { > km_status stat =3D KM_OK; > struct threadInfo* Tinfo =3D (struct threadInfo*)vargp; > > do { > stat =3D pthread_rwlock_trywrlock(Tinfo->rwlock); > if (KM_OK =3D=3D stat) { > printf("[INFO] - FIRST thread 0x%x locked %p \n", *(Tinfo->= tid), Tinfo->rwlock); > sleep(10); > stat =3D pthread_rwlock_unlock(Tinfo->rwlock); > if (KM_OK =3D=3D stat) { > printf("[INFO] FIRST thread 0x%x released %p \n", *(Tin= fo->tid), Tinfo->rwlock); > sleep(1); > } > } > }while(KM_OK !=3D stat); > return NULL; > } > > > void *secondThreadFunction(void *vargp) > { > km_status stat =3D KM_OK; > struct threadInfo* Tinfo =3D (struct threadInfo*)vargp; > > sleep(5); > do { > stat =3D pthread_rwlock_unlock(Tinfo->rwlock); > if (KM_OK =3D=3D stat) { > printf("[INFO] SECOND thread 0x%x released %p \n", *(Tinfo-= >tid), Tinfo->rwlock); > sleep(1); > } else > printf("[INFO] SECOND thread 0x%x try_to_released %p erro s= tatus is: %d \n", *(Tinfo->tid), Tinfo->rwlock,stat); > > }while(KM_OK !=3D stat); > return NULL; > } > > void *thirdThreadFunction(void *vargp) > { > km_status stat =3D KM_OK; > struct threadInfo* Tinfo =3D (struct threadInfo*)vargp; > > sleep(2); > do { > stat =3D pthread_rwlock_trywrlock(Tinfo->rwlock); > if (KM_OK =3D=3D stat) { > printf("[INFO] THIRD thread 0X%x locked %x\n", *(Tinfo->tid= ), Tinfo->rwlock); > sleep(5); > } > else { > printf("[ERROR]: THIRD thread 0x%x failed Locking %p status= is %d\n", *(Tinfo->tid), Tinfo->rwlock,stat); > sleep(1); > } > }while(KM_OK !=3D stat); > return NULL; > } > > void main() > { > km_status stat =3D KM_OK; > /* km_rwlock lock; */ > pthread_rwlock_t rwlock; > pthread_t lockerTid =3D 0, releaseTid =3D 0, thirdTid=3D0; > struct threadInfo firstTinfo, secondTinfo, thirdTinfo; > > /* stat =3D km_rwlock_init(&rwlock, KM_TRUE); */ > stat =3D pthread_rwlock_init (&rwlock, NULL); > > if (KM_OK =3D=3D stat) { > printf("read\\writer lock initialized\n"); > printf("Before Thread\n"); > > firstTinfo.tid =3D &lockerTid; > firstTinfo.rwlock =3D &rwlock; > secondTinfo.tid =3D &releaseTid; > secondTinfo.rwlock =3D &rwlock; > thirdTinfo.tid =3D &thirdTid; > thirdTinfo.rwlock =3D &rwlock; > > > pthread_create(&lockerTid, NULL, lockerThreadFunction, &firstTi= nfo); > pthread_create(&releaseTid, NULL, secondThreadFunction, &secon= dTinfo); > pthread_create(&thirdTid, NULL, thirdThreadFunction, &thirdTinf= o); > printf("After Thread %x\n", lockerTid); > > pthread_join(lockerTid, NULL); > pthread_join(releaseTid, NULL); > pthread_join(thirdTid, NULL); > > > > the output we saw is this: > > > the ouput we saw is this: > > [root@Rocky85Mozes thread_lock]# ./rw_test > read\writer lock initialized > Before Thread > [INFO] - FIRST thread 0x461f700 locked 0x7ffcda053cc0 > After Thread 461f700 > [ERROR]: THIRD thread 0x361d700 failed Locking 0x7ffcda053cc0 status is = 16 -> first thread take the rwlock > [ERROR]: THIRD thread 0x361d700 failed Locking 0x7ffcda053cc0 status is = 16 > [ERROR]: THIRD thread 0x361d700 failed Locking 0x7ffcda053cc0 status is = 16 > [INFO] SECOND thread 0x3e1e700 released 0x7ffcda053cc0 -> Second threa= d unlock the rwlock -- > and get OK!! > [ERROR]: THIRD thread 0x361d700 failed Locking 0x7ffcda053cc0 status is = 16 > [ERROR]: THIRD thread 0x361d700 failed Locking 0x7ffcda053cc0 status is = 16 > [ERROR]: THIRD thread 0x361d700 failed Locking 0x7ffcda053cc0 status is = 16 > [ERROR]: THIRD thread 0x361d700 failed Locking 0x7ffcda053cc0 status is = 16 > [ERROR]: THIRD thread 0x361d700 failed Locking 0x7ffcda053cc0 status is = 16 > [INFO] FIRST thread 0x461f700 released 0x7ffcda053cc0 > [ERROR]: THIRD thread 0x361d700 failed Locking 0x7ffcda053cc0 status is = 16 > > > -----Original Message----- > From: David Mozes > Sent: Sunday, March 13, 2022 12:23 PM > To: Florian Weimer > Cc: libc-help@sourceware.org > Subject: RE: rwlock different behavior on glibc 2.28 then on previous ve= rsions > > Thx Florin, > > > -----Original Message----- > From: Florian Weimer > Sent: Friday, March 11, 2022 3:59 PM > To: David Mozes > Cc: libc-help@sourceware.org > Subject: Re: rwlock different behavior on glibc 2.28 then on previous ve= rsions > > * David Mozes: > >> On the previous version of Glibc (before the commit) We could release >> write lock with different thread as the one that owned the lock (If we >> like) . > Sorry, this misuse of the API has always been undefined according to > POSIX (=E2=80=9CResults are undefined if the read-write lock rwlock is n= ot held > by the calling thread.=E2=80=9D). > > >> Correct, but practically we can do it on the user's responsibility. >>> Do you know if this "if" solved some synchronization issue or just enf= orced the undefined API? >> This is help very much for async program that has a many threads that >> communicate with some target. And we like to define a call back >> function instead of blocking on aio thread that send the data in order >> to release the rwlock.this improves the performance dramatically . > Could you use a different synchronization object (perhaps a condition > variable)? > >>> If we use a different synchronization object like semaphores, conditio= n variable (by the way they use mutex under the same API agreement), we w= ill need to write self rwlock , which has less performance than other unde= fined states. >>> If we like to keep the API agreement, why not define the different asy= nc programming unlock functions? > Thanks > Florian > > Thx > David