You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
|
3
(4) |
4
(5) |
5
(2) |
6
|
7
(2) |
8
(4) |
|
9
(1) |
10
(7) |
11
(4) |
12
(4) |
13
(8) |
14
(6) |
15
(3) |
|
16
(4) |
17
|
18
|
19
|
20
(6) |
21
|
22
|
|
23
|
24
(1) |
25
(8) |
26
(12) |
27
(1) |
28
(9) |
29
(9) |
|
30
(3) |
31
(4) |
|
|
|
|
|
|
From: Bart V. A. <bva...@ac...> - 2010-05-20 10:05:41
|
On Thu, May 20, 2010 at 8:02 AM, Konstantin Serebryany <
kon...@gm...> wrote:
>
> I have a test case which will not deadlock, but helgrind reports "lock
> order "0x600DA0 before 0x600DE0" violated".
> The code does indeed have lock order inversion, but due to reader locks no
> deadlock is possible.
> I don't have a strong opinion on whether this case should be reported or
> not, just want to know what do you think.
>
> Thanks,
>
> --kcc
>
>
> % cat rd_dl.cc
> #include <pthread.h>
>
> pthread_rwlock_t l1, l2;
>
> void *f1(void *) {
> pthread_rwlock_wrlock(&l1);
> pthread_rwlock_rdlock(&l2);
> pthread_rwlock_unlock(&l2);
> pthread_rwlock_unlock(&l1);
> }
>
> void *f2(void *) {
> pthread_rwlock_rdlock(&l2);
> pthread_rwlock_wrlock(&l1);
> pthread_rwlock_unlock(&l1);
> pthread_rwlock_unlock(&l2);
> }
>
> int main() {
> pthread_t t1, t2;
> pthread_rwlock_init(&l1, NULL);
> pthread_rwlock_init(&l2, NULL);
> pthread_create(&t1, NULL, f1, NULL);
> pthread_create(&t2, NULL, f2, NULL);
> pthread_join(t1, NULL);
> pthread_join(t2, NULL);
> }
>
>
Obtaining a writer lock from a thread that already holds a reader lock, as
in f2(), will cause a deadlock sooner or later if multiple threads do this
simultaneously. Thread checking tools should always report attempts to
obtain a writer lock while a reader lock is being held.
Bart.
|
|
From: Konstantin S. <kon...@gm...> - 2010-05-20 08:44:10
|
On Thu, May 20, 2010 at 1:00 PM, Julian Seward <js...@ac...> wrote: > > > > > I have a test case which will not deadlock, but helgrind reports > "lock > > > > order "0x600DA0 before 0x600DE0" violated". > > > > The code does indeed have lock order inversion, but due to reader > locks > > > > no deadlock is possible. > > > My question is whether an ideal deadlock detector should or should not > > report such lock order violations. > > (I don't know the answer!) > > /me no understand .. if you are sure that this example can never deadlock, > then an ideal lock-order-error detector should not report any error, > because there is no error. (Or did I miss something?) > There is no deadlock, but this looks like a bad coding style and it is easy to make changes that will actually lead to deadlock. --kcc > > J > |
|
From: Julian S. <js...@ac...> - 2010-05-20 08:38:08
|
> > > I have a test case which will not deadlock, but helgrind reports "lock > > > order "0x600DA0 before 0x600DE0" violated". > > > The code does indeed have lock order inversion, but due to reader locks > > > no deadlock is possible. > My question is whether an ideal deadlock detector should or should not > report such lock order violations. > (I don't know the answer!) /me no understand .. if you are sure that this example can never deadlock, then an ideal lock-order-error detector should not report any error, because there is no error. (Or did I miss something?) J |
|
From: Konstantin S. <kon...@gm...> - 2010-05-20 08:35:40
|
On Thu, May 20, 2010 at 12:35 PM, Julian Seward <js...@ac...> wrote: > On Thursday 20 May 2010, Konstantin Serebryany wrote: > > Hi, > > > > I have a test case which will not deadlock, but helgrind reports "lock > > order "0x600DA0 before 0x600DE0" violated". > > The code does indeed have lock order inversion, but due to reader locks > no > > deadlock is possible. > > I don't have a strong opinion on whether this case should be reported or > > not, just want to know what do you think. > > The lock order checking in Helgrind doesn't understand the difference > between reader/writer locks and normal ones, and assumes all locks are > normal ones. So it probably can't handle this case properly. > Yea, I understand that. My question is whether an ideal deadlock detector should or should not report such lock order violations. (I don't know the answer!) --kcc > > Suggestions for a better algorithm welcomed. I think Bart might know > more about this .. I remember some mail about this problem some time > in the past. > > J > |
|
From: Julian S. <js...@ac...> - 2010-05-20 08:12:56
|
On Thursday 20 May 2010, Konstantin Serebryany wrote: > Hi, > > I have a test case which will not deadlock, but helgrind reports "lock > order "0x600DA0 before 0x600DE0" violated". > The code does indeed have lock order inversion, but due to reader locks no > deadlock is possible. > I don't have a strong opinion on whether this case should be reported or > not, just want to know what do you think. The lock order checking in Helgrind doesn't understand the difference between reader/writer locks and normal ones, and assumes all locks are normal ones. So it probably can't handle this case properly. Suggestions for a better algorithm welcomed. I think Bart might know more about this .. I remember some mail about this problem some time in the past. J |
|
From: Konstantin S. <kon...@gm...> - 2010-05-20 06:03:17
|
Hi,
I have a test case which will not deadlock, but helgrind reports "lock order
"0x600DA0 before 0x600DE0" violated".
The code does indeed have lock order inversion, but due to reader locks no
deadlock is possible.
I don't have a strong opinion on whether this case should be reported or
not, just want to know what do you think.
Thanks,
--kcc
% cat rd_dl.cc
#include <pthread.h>
pthread_rwlock_t l1, l2;
void *f1(void *) {
pthread_rwlock_wrlock(&l1);
pthread_rwlock_rdlock(&l2);
pthread_rwlock_unlock(&l2);
pthread_rwlock_unlock(&l1);
}
void *f2(void *) {
pthread_rwlock_rdlock(&l2);
pthread_rwlock_wrlock(&l1);
pthread_rwlock_unlock(&l1);
pthread_rwlock_unlock(&l2);
}
int main() {
pthread_t t1, t2;
pthread_rwlock_init(&l1, NULL);
pthread_rwlock_init(&l2, NULL);
pthread_create(&t1, NULL, f1, NULL);
pthread_create(&t2, NULL, f2, NULL);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
}
% g++ -g -lpthread rd_dl.cc
% ~/valgrind/trunk/inst/bin/valgrind --tool=helgrind ./a.out
==26851== Helgrind, a thread error detector
==26851== Copyright (C) 2007-2009, and GNU GPL'd, by OpenWorks LLP et al.
==26851== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright
info
==26851== Command: ./a.out
==26851==
==26851== Thread #3 was created
==26851== at 0x58907D0: clone (in /usr/grte/v1/lib64/libc-2.3.6.so)
==26851== by 0x4E2A574: pthread_create@@GLIBC_2.2.5 (in
/usr/grte/v1/lib64/libpthread-2.3.6.so)
==26851== by 0x4C21210: pthread_create_WRK (hg_intercepts.c:241)
==26851== by 0x4C212B9: pthread_create@* (hg_intercepts.c:268)
==26851== by 0x400861: main (rd_dl.cc:24)
==26851==
==26851== Thread #3: lock order "0x600DA0 before 0x600DE0" violated
==26851== at 0x4C1ED6F: pthread_rwlock_wrlock (hg_intercepts.c:1380)
==26851== by 0x4008A4: f2(void*) (rd_dl.cc:14)
==26851== by 0x4C21342: mythread_wrapper (hg_intercepts.c:213)
==26851== by 0x4E2A0C9: start_thread (in /usr/grte/v1/lib64/
libpthread-2.3.6.so)
==26851== by 0x5890811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so)
==26851== Required order was established by acquisition of lock at
0x600DA0
==26851== at 0x4C1ED6F: pthread_rwlock_wrlock (hg_intercepts.c:1380)
==26851== by 0x4008D0: f1(void*) (rd_dl.cc:6)
==26851== by 0x4C21342: mythread_wrapper (hg_intercepts.c:213)
==26851== by 0x4E2A0C9: start_thread (in /usr/grte/v1/lib64/
libpthread-2.3.6.so)
==26851== by 0x5890811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so)
==26851== followed by a later acquisition of lock at 0x600DE0
==26851== at 0x4C1EEFC: pthread_rwlock_rdlock (hg_intercepts.c:1427)
==26851== by 0x4008DA: f1(void*) (rd_dl.cc:7)
==26851== by 0x4C21342: mythread_wrapper (hg_intercepts.c:213)
==26851== by 0x4E2A0C9: start_thread (in /usr/grte/v1/lib64/
libpthread-2.3.6.so)
==26851== by 0x5890811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so)
|