Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #117659 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2023-11-08 15:56 +0100 |
| Last post | 2023-11-13 22:46 -0800 |
| Articles | 20 on this page of 259 — 9 participants |
Back to article view | Back to comp.lang.c++
A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-08 15:56 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-08 19:31 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-08 20:56 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-08 23:25 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:33 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:36 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:38 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:42 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:08 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:11 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:12 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:17 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:35 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:39 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:40 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:41 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:42 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:44 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:44 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:45 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:48 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:50 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:58 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 22:46 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:52 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 21:10 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-15 06:07 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-17 21:16 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-18 04:06 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-18 12:53 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-18 20:04 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-18 19:24 +0000
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-18 20:29 +0000
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-18 21:46 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-18 20:18 -0500
Re: A Java- / .NET-like monitor Michael S <already5chosen@yahoo.com> - 2023-11-24 01:14 +0200
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 21:35 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 08:59 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 01:17 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 10:25 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-24 15:59 +0000
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-24 18:33 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 15:39 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-25 00:08 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 16:27 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-25 14:47 -0800
Re: A Java- / .NET-like monitor "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2023-11-25 13:02 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-25 17:28 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-25 18:48 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-25 18:09 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-25 13:12 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-25 18:10 +0000
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-25 19:30 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-25 14:57 -0800
Re: A Java- / .NET-like monitor Michael S <already5chosen@yahoo.com> - 2023-11-26 01:29 +0200
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-25 15:56 -0800
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-26 13:54 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-26 14:38 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-26 16:28 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-26 18:51 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-26 20:27 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-26 14:38 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-26 15:00 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 05:23 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-27 10:38 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 10:55 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-27 11:19 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 12:32 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-26 22:55 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 15:15 -0800
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-28 09:03 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-25 13:58 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-18 20:09 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-19 05:58 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-19 05:02 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-19 07:00 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-19 06:08 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-19 12:05 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-19 12:08 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-19 12:11 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-19 12:17 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-20 13:26 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-20 12:18 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-21 10:25 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 21:38 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 08:56 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 01:22 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 19:10 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 15:43 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-25 13:04 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-25 15:06 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-26 11:35 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-26 15:45 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 05:24 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-26 22:22 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 08:57 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 00:28 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 09:34 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 14:59 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 14:59 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 15:19 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-28 15:13 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-18 12:46 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-18 21:47 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-18 14:02 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-18 20:20 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-20 13:12 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 08:01 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 08:01 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:50 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-11 17:45 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-12 05:43 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-12 05:02 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-12 11:00 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-12 17:18 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 07:33 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 07:47 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 12:50 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 06:20 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 21:21 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 07:44 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 22:51 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 22:55 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 08:00 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 08:07 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 23:08 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 23:07 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-14 15:18 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 16:46 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-14 16:09 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 17:41 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 18:41 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 12:25 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 14:25 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-14 22:50 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:07 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-15 05:57 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:08 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 03:59 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-16 15:02 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 18:12 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-16 17:45 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 15:24 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-12 17:53 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-12 12:51 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-12 19:33 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-13 04:50 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-13 22:05 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-14 03:30 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 22:35 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 20:26 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:11 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-15 23:07 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-16 06:39 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-16 21:48 -0500
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-17 16:29 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-17 10:22 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-17 18:37 +0000
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-18 00:45 +0000
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-18 02:30 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 11:11 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 07:35 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-13 15:05 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 16:36 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 17:24 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-12 12:48 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-12 19:29 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-12 16:44 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-16 14:16 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-13 04:48 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 14:32 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-13 21:27 -0500
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-14 15:12 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 20:35 -0500
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-13 21:58 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-14 03:27 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 21:28 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 21:29 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 20:47 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:18 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:20 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-15 21:26 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-16 00:25 -0500
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 20:42 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-28 15:32 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-12 19:17 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-09 05:17 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:18 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:20 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:19 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:20 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-08 23:51 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:10 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 15:32 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:35 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:17 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:22 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:27 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:29 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:31 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:34 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:36 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:40 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:42 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 07:32 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 22:54 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 23:01 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 23:03 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:30 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:32 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 14:59 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-08 19:49 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-08 18:16 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 13:49 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:37 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:40 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:39 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 13:41 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:36 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:41 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-08 18:16 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 10:07 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-09 01:11 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 10:17 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-09 01:22 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-09 01:23 -0800
Re: A Java- / .NET-like monitor Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-11-10 13:56 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-10 15:08 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-10 15:15 +0100
Re: A Java- / .NET-like monitor Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-11-11 02:59 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-10 12:44 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-11 04:53 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-10 20:09 -0800
Re: A Java- / .NET-like monitor Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-11-11 04:25 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-11 07:07 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-11 11:41 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-11 16:39 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-11 11:42 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-11 17:49 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-12 05:40 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-12 12:46 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 23:13 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 10:04 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 01:21 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 11:00 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 02:08 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 11:23 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 12:27 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 12:29 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-15 05:54 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:21 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 04:00 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 19:10 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-16 03:21 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 06:36 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-16 13:06 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-17 06:57 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-11 11:41 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 22:46 -0800
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-11-16 18:12 +0100 |
| Message-ID | <uj5ih0$2booh$1@raubtier-asyl.eternal-september.org> |
| In reply to | #117843 |
Am 16.11.2023 um 16:02 schrieb Scott Lurndal: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 15.11.2023 um 21:08 schrieb Chris M. Thomasson: >> >>> Are you sure its 100% atomic for use in multi-thread sync algorithms? >> >> If MSVC generates that code it's atomic. > > No, if Intel architecture documentation specifies that it is > single-copy atomic, then it is single-copy atomic. MSVC relies for sure on the right behaviour. > MSVC is just a poor-to-middling C compiler. MSVC has the strongest C++20-conformance but the weakest optimizer.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-11-16 17:45 +0000 |
| Message-ID | <_ys5N.12946$ayBd.1996@fx07.iad> |
| In reply to | #117844 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 16.11.2023 um 16:02 schrieb Scott Lurndal: >> Bonita Montero <Bonita.Montero@gmail.com> writes: >>> Am 15.11.2023 um 21:08 schrieb Chris M. Thomasson: >>> >>>> Are you sure its 100% atomic for use in multi-thread sync algorithms? >>> >>> If MSVC generates that code it's atomic. >> >> No, if Intel architecture documentation specifies that it is >> single-copy atomic, then it is single-copy atomic. > >MSVC relies for sure on the right behaviour. Right. Keep thinking that. > >> MSVC is just a poor-to-middling C compiler. > >MSVC has the strongest C++20-conformance but the weakest optimizer. Faint praise, indeed. Nobody other than Herb cares about C++20 conformance. Most real world C++ code relies on C++11 for portability. Most of our systems and our customers systems don't even support C++17.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-27 15:24 -0800 |
| Message-ID | <uk38fg$3v44n$1@dont-email.me> |
| In reply to | #117845 |
On 11/16/2023 9:45 AM, Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 16.11.2023 um 16:02 schrieb Scott Lurndal: >>> Bonita Montero <Bonita.Montero@gmail.com> writes: >>>> Am 15.11.2023 um 21:08 schrieb Chris M. Thomasson: >>>> >>>>> Are you sure its 100% atomic for use in multi-thread sync algorithms? >>>> >>>> If MSVC generates that code it's atomic. >>> >>> No, if Intel architecture documentation specifies that it is >>> single-copy atomic, then it is single-copy atomic. >> >> MSVC relies for sure on the right behaviour. > > Right. Keep thinking that. > >> >>> MSVC is just a poor-to-middling C compiler. >> >> MSVC has the strongest C++20-conformance but the weakest optimizer. > > Faint praise, indeed. Nobody other than Herb cares about C++20 conformance. ;^D Sutters mill... > > Most real world C++ code relies on C++11 for portability. Most > of our systems and our customers systems don't even support C++17. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-11-12 17:53 +0000 |
| Message-ID | <Pi84N.104$ayBd.46@fx07.iad> |
| In reply to | #117762 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 12.11.2023 um 06:02 schrieb Kaz Kylheku: > >> I don't suspect that is part of Mesa semantics. (It's definitely part of >> Hoare semantics.) Do you have a reference? > >Wikipedia (https://en.wikipedia.org/wiki/Monitor_(synchronization): >"With nonblocking condition variables (also called "Mesa style" >condition variables or "signal and continue" condition variables), >signaling does not cause the signaling thread to lose occupancy >of the monitor. Instead the signaled threads are moved to the e >queue." > >> Since under Mesa semantics, threads re-acquire the mutex with fewer >> guarantees and must re-test the desired condition, Mesa semantics >> supports the more efficient protocol of signaling outside of the >> monitor. > >This is a theoretical advantage. In fact, a combination of mutex >and condition variable, like a monitor implicitly is, is intended >for procuder-consumer patterns. And at this point it never happens >that you want to signal something but don't modify a common state. > > >> If you're using POSIX mutexes and conditions, you should call >> pthread_cond_signal and pthread_cond_broadcast outside of the >> mutex, whenever possible. > >That actually never happens because you have to lock the mutex >anyway. No, you don't. If you updated the predicate that the condition variable is monitoring while holding the mutex, you should release the mutex before signaling or broadcasting the condition variable to avoid unnecessary context switches.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-12 12:51 -0800 |
| Message-ID | <uirdsh$7lqi$3@dont-email.me> |
| In reply to | #117764 |
On 11/12/2023 9:53 AM, Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 12.11.2023 um 06:02 schrieb Kaz Kylheku: >> >>> I don't suspect that is part of Mesa semantics. (It's definitely part of >>> Hoare semantics.) Do you have a reference? >> >> Wikipedia (https://en.wikipedia.org/wiki/Monitor_(synchronization): >> "With nonblocking condition variables (also called "Mesa style" >> condition variables or "signal and continue" condition variables), >> signaling does not cause the signaling thread to lose occupancy >> of the monitor. Instead the signaled threads are moved to the e >> queue." >> >>> Since under Mesa semantics, threads re-acquire the mutex with fewer >>> guarantees and must re-test the desired condition, Mesa semantics >>> supports the more efficient protocol of signaling outside of the >>> monitor. >> >> This is a theoretical advantage. In fact, a combination of mutex >> and condition variable, like a monitor implicitly is, is intended >> for procuder-consumer patterns. And at this point it never happens >> that you want to signal something but don't modify a common state. >> >> >>> If you're using POSIX mutexes and conditions, you should call >>> pthread_cond_signal and pthread_cond_broadcast outside of the >>> mutex, whenever possible. >> >> That actually never happens because you have to lock the mutex >> anyway. > > No, you don't. If you updated the predicate that the condition > variable is monitoring while holding the mutex, you should release > the mutex before signaling or broadcasting the condition variable > to avoid unnecessary context switches. Yup. Actually, there was an old discussion about this around 20 ish years ago back on comp.programming.threads. David Butenhof was involved.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-11-12 19:33 -0500 |
| Message-ID | <b9e4N.20671$Ee89.15587@fx17.iad> |
| In reply to | #117764 |
Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 12.11.2023 um 06:02 schrieb Kaz Kylheku: >> >>> I don't suspect that is part of Mesa semantics. (It's definitely part of >>> Hoare semantics.) Do you have a reference? >> >> Wikipedia (https://en.wikipedia.org/wiki/Monitor_(synchronization): >> "With nonblocking condition variables (also called "Mesa style" >> condition variables or "signal and continue" condition variables), >> signaling does not cause the signaling thread to lose occupancy >> of the monitor. Instead the signaled threads are moved to the e >> queue." >> >>> Since under Mesa semantics, threads re-acquire the mutex with fewer >>> guarantees and must re-test the desired condition, Mesa semantics >>> supports the more efficient protocol of signaling outside of the >>> monitor. >> >> This is a theoretical advantage. In fact, a combination of mutex >> and condition variable, like a monitor implicitly is, is intended >> for procuder-consumer patterns. And at this point it never happens >> that you want to signal something but don't modify a common state. >> >> >>> If you're using POSIX mutexes and conditions, you should call >>> pthread_cond_signal and pthread_cond_broadcast outside of the >>> mutex, whenever possible. >> >> That actually never happens because you have to lock the mutex >> anyway. > > No, you don't. If you updated the predicate that the condition > variable is monitoring while holding the mutex, you should release > the mutex before signaling or broadcasting the condition variable > to avoid unnecessary context switches. > Why would you have additional context switches if you signal before releasing the lock?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-13 04:50 +0000 |
| Message-ID | <20231112204849.10@kylheku.com> |
| In reply to | #117770 |
On 2023-11-13, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: > Scott Lurndal wrote: >> No, you don't. If you updated the predicate that the condition >> variable is monitoring while holding the mutex, you should release >> the mutex before signaling or broadcasting the condition variable >> to avoid unnecessary context switches. >> > Why would you have additional context switches if you signal before > releasing the lock? Because of the situation that the thread which was signaled is trying to acquire the mutex, which, stupidly, the signaling thread is still holding. So, oops, back it goes into suspended state, and we have to context switch to the mutex holder which has to release the mutex and then switch to that signaled thread again. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-11-13 22:05 -0500 |
| Message-ID | <euB4N.6863$%p%e.3900@fx43.iad> |
| In reply to | #117773 |
Kaz Kylheku wrote: > On 2023-11-13, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: >> Scott Lurndal wrote: >>> No, you don't. If you updated the predicate that the condition >>> variable is monitoring while holding the mutex, you should release >>> the mutex before signaling or broadcasting the condition variable >>> to avoid unnecessary context switches. >>> >> Why would you have additional context switches if you signal before >> releasing the lock? > > Because of the situation that the thread which was signaled is > trying to acquire the mutex, which, stupidly, the signaling thread > is still holding. So, oops, back it goes into suspended state, and we > have to context switch to the mutex holder which has to release the > mutex and then switch to that signaled thread again. > Please see my response to your other post. "as-if" calling of pthread_mutex_lock does not prescribe actually calling it. Nothing in the standard prevents pthread_cond_signal from doing all the job of stuffing the unblocked threads to the mutex waiting list in accordance with some scheduling policy. They don't really need to leave the non-runnable state until the mutex is released.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-14 03:30 +0000 |
| Message-ID | <20231113192822.953@kylheku.com> |
| In reply to | #117785 |
On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: > Kaz Kylheku wrote: >> Because of the situation that the thread which was signaled is >> trying to acquire the mutex, which, stupidly, the signaling thread >> is still holding. So, oops, back it goes into suspended state, and we >> have to context switch to the mutex holder which has to release the >> mutex and then switch to that signaled thread again. >> > Please see my response to your other post. "as-if" calling of > pthread_mutex_lock does not prescribe actually calling it. Nothing in > the standard prevents pthread_cond_signal from doing all the job of > stuffing the unblocked threads to the mutex waiting list in accordance > with some scheduling policy. Have you noticed how no mutex appears in the pthread_cond_signal API? -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-13 22:35 -0800 |
| Message-ID | <uiv4fh$14o4p$1@dont-email.me> |
| In reply to | #117787 |
On 11/13/2023 7:30 PM, Kaz Kylheku wrote: > On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: >> Kaz Kylheku wrote: >>> Because of the situation that the thread which was signaled is >>> trying to acquire the mutex, which, stupidly, the signaling thread >>> is still holding. So, oops, back it goes into suspended state, and we >>> have to context switch to the mutex holder which has to release the >>> mutex and then switch to that signaled thread again. >>> >> Please see my response to your other post. "as-if" calling of >> pthread_mutex_lock does not prescribe actually calling it. Nothing in >> the standard prevents pthread_cond_signal from doing all the job of >> stuffing the unblocked threads to the mutex waiting list in accordance >> with some scheduling policy. > > Have you noticed how no mutex appears in the pthread_cond_signal API? > DING!
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-11-14 20:26 -0500 |
| Message-ID | <97V4N.19464$Wzw6.11650@fx13.iad> |
| In reply to | #117787 |
Kaz Kylheku wrote: > On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: >> Kaz Kylheku wrote: >>> Because of the situation that the thread which was signaled is >>> trying to acquire the mutex, which, stupidly, the signaling thread >>> is still holding. So, oops, back it goes into suspended state, and we >>> have to context switch to the mutex holder which has to release the >>> mutex and then switch to that signaled thread again. >>> >> Please see my response to your other post. "as-if" calling of >> pthread_mutex_lock does not prescribe actually calling it. Nothing in >> the standard prevents pthread_cond_signal from doing all the job of >> stuffing the unblocked threads to the mutex waiting list in accordance >> with some scheduling policy. > > Have you noticed how no mutex appears in the pthread_cond_signal API? > Of course but so what? Nothing prevents the implementation from listing the temporarily released mutices of the waiting pthread_cond_wait callers in the cond var where pthread_cond_signal can access them. Or, possibly even better, keeping a pointer to them with the threads waiting for the condvar (there can only be at most one such temporarily released mutex per the waiting thread). And the threads waiting for the condvar are accessible for the pthread_cond_signal according to the spec.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-15 12:11 -0800 |
| Message-ID | <uj38lm$1skku$3@dont-email.me> |
| In reply to | #117819 |
On 11/14/2023 5:26 PM, Pavel wrote: > Kaz Kylheku wrote: >> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> >> wrote: >>> Kaz Kylheku wrote: >>>> Because of the situation that the thread which was signaled is >>>> trying to acquire the mutex, which, stupidly, the signaling thread >>>> is still holding. So, oops, back it goes into suspended state, and we >>>> have to context switch to the mutex holder which has to release the >>>> mutex and then switch to that signaled thread again. >>>> >>> Please see my response to your other post. "as-if" calling of >>> pthread_mutex_lock does not prescribe actually calling it. Nothing in >>> the standard prevents pthread_cond_signal from doing all the job of >>> stuffing the unblocked threads to the mutex waiting list in accordance >>> with some scheduling policy. >> >> Have you noticed how no mutex appears in the pthread_cond_signal API? >> > Of course but so what? Nothing prevents the implementation from listing > the temporarily released mutices of the waiting pthread_cond_wait > callers in the cond var where pthread_cond_signal can access them. > > Or, possibly even better, keeping a pointer to them with the threads > waiting for the condvar (there can only be at most one such temporarily > released mutex per the waiting thread). And the threads waiting for the > condvar are accessible for the pthread_cond_signal according to the spec. Just as long as the implementation works wrt calling pthread_cond_signal/broadcast outside of the mutex. If not, it is broken.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-11-15 23:07 -0500 |
| Message-ID | <EAg5N.8455$pgLd.5478@fx05.iad> |
| In reply to | #117829 |
Chris M. Thomasson wrote: > On 11/14/2023 5:26 PM, Pavel wrote: >> Kaz Kylheku wrote: >>> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> >>> wrote: >>>> Kaz Kylheku wrote: >>>>> Because of the situation that the thread which was signaled is >>>>> trying to acquire the mutex, which, stupidly, the signaling thread >>>>> is still holding. So, oops, back it goes into suspended state, and we >>>>> have to context switch to the mutex holder which has to release the >>>>> mutex and then switch to that signaled thread again. >>>>> >>>> Please see my response to your other post. "as-if" calling of >>>> pthread_mutex_lock does not prescribe actually calling it. Nothing in >>>> the standard prevents pthread_cond_signal from doing all the job of >>>> stuffing the unblocked threads to the mutex waiting list in accordance >>>> with some scheduling policy. >>> >>> Have you noticed how no mutex appears in the pthread_cond_signal API? >>> >> Of course but so what? Nothing prevents the implementation from >> listing the temporarily released mutices of the waiting >> pthread_cond_wait callers in the cond var where pthread_cond_signal >> can access them. >> >> Or, possibly even better, keeping a pointer to them with the threads >> waiting for the condvar (there can only be at most one such >> temporarily released mutex per the waiting thread). And the threads >> waiting for the condvar are accessible for the pthread_cond_signal >> according to the spec. > > Just as long as the implementation works wrt calling > pthread_cond_signal/broadcast outside of the mutex. If not, it is broken. I am unsure where from that discussion of implementation came. The *spec* permits this (signalling without holding the mutex), just warns that a predictable scheduling behavior cannot be achieved then. What would you consider an example of a "non-working" implementation? Does my example that illustrates how a higher-prio thread may never make progress is of a broken implementation in your opinion?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-16 06:39 +0000 |
| Message-ID | <20231115223459.609@kylheku.com> |
| In reply to | #117838 |
On 2023-11-16, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: > I am unsure where from that discussion of implementation came. The > *spec* permits this (signalling without holding the mutex), just warns > that a predictable scheduling behavior cannot be achieved then. The spec is supposed to tell implementors what to make. Loose wording like this is dangerous. An implementor is free to interpret it like this: whenever a program calls pthread_cond_signal, and it so happens that the calling threads owns no mutex whatsoever, the implementation is free to set a flag somewhere, based on which it will willfully damage the integrity of the scheduling implementation somehow, so that it behaves like crap. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-11-16 21:48 -0500 |
| Message-ID | <XvA5N.62534$wvv7.58333@fx14.iad> |
| In reply to | #117841 |
Kaz Kylheku wrote: > On 2023-11-16, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: >> I am unsure where from that discussion of implementation came. The >> *spec* permits this (signalling without holding the mutex), just warns >> that a predictable scheduling behavior cannot be achieved then. > > The spec is supposed to tell implementors what to make. > > Loose wording like this is dangerous. An implementor is free to > interpret it like this: whenever a program calls pthread_cond_signal, > and it so happens that the calling threads owns no mutex whatsoever, the > implementation is free to set a flag somewhere, based on which it will > willfully damage the integrity of the scheduling implementation somehow, > so that it behaves like crap. > If your complaint is about "predictable scheduling behavior" not being defined in the standard, I understand and sympathize. It could be better defined. When POSIX threads were developed, this was kinda obvious because RT guys required that and they know what they mean by that (meaning -- more or less agree). This is not a good excuse for not spelling it in the standard of course. See if this old posting of David Butenhof, one of the spec authors may clarify the concept: https://austin-group-l.opengroup.narkive.com/lKcmfoRI/predictable-scheduling-behavior-in-pthread-cond-broadcast
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-11-17 16:29 +0000 |
| Message-ID | <oxM5N.70257$wvv7.26310@fx14.iad> |
| In reply to | #117848 |
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes: >Kaz Kylheku wrote: >> On 2023-11-16, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: >>> I am unsure where from that discussion of implementation came. The >>> *spec* permits this (signalling without holding the mutex), just warns >>> that a predictable scheduling behavior cannot be achieved then. >> >> The spec is supposed to tell implementors what to make. >> >> Loose wording like this is dangerous. An implementor is free to >> interpret it like this: whenever a program calls pthread_cond_signal, >> and it so happens that the calling threads owns no mutex whatsoever, the >> implementation is free to set a flag somewhere, based on which it will >> willfully damage the integrity of the scheduling implementation somehow, >> so that it behaves like crap. >> >If your complaint is about "predictable scheduling behavior" not being >defined in the standard, I understand and sympathize. It could be better >defined. When POSIX threads were developed, this was kinda obvious >because RT guys required that and they know what they mean by that >(meaning -- more or less agree). This is not a good excuse for not >spelling it in the standard of course. > >See if this old posting of David Butenhof, one of the spec authors may >clarify the concept: > >https://austin-group-l.opengroup.narkive.com/lKcmfoRI/predictable-scheduling-behavior-in-pthread-cond-broadcast When David wrote that, multiprocessor systems were still rare and limited to very expensive systems (e.g. Sequent) (and for the most part, weren't running real-time code). I was on the X/Open working group for a few years during that time period, and one of my collegues at SGI was part of the 1003.4 working group. thirty years later, pthread_cond_t is heavily used by non-realtime code, where such priority inversions (usually very transient) don't matter. For the number of cases where pthread_cond_t is used in hard real-time code, the appropriate techniques (i.e. holding the mutex while signaling the condition) are available.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-17 10:22 -0800 |
| Message-ID | <uj8b1b$2tap5$1@dont-email.me> |
| In reply to | #117853 |
On 11/17/2023 8:29 AM, Scott Lurndal wrote: > Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes: >> Kaz Kylheku wrote: >>> On 2023-11-16, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: >>>> I am unsure where from that discussion of implementation came. The >>>> *spec* permits this (signalling without holding the mutex), just warns >>>> that a predictable scheduling behavior cannot be achieved then. >>> >>> The spec is supposed to tell implementors what to make. >>> >>> Loose wording like this is dangerous. An implementor is free to >>> interpret it like this: whenever a program calls pthread_cond_signal, >>> and it so happens that the calling threads owns no mutex whatsoever, the >>> implementation is free to set a flag somewhere, based on which it will >>> willfully damage the integrity of the scheduling implementation somehow, >>> so that it behaves like crap. >>> >> If your complaint is about "predictable scheduling behavior" not being >> defined in the standard, I understand and sympathize. It could be better >> defined. When POSIX threads were developed, this was kinda obvious >> because RT guys required that and they know what they mean by that >> (meaning -- more or less agree). This is not a good excuse for not >> spelling it in the standard of course. >> >> See if this old posting of David Butenhof, one of the spec authors may >> clarify the concept: >> >> https://austin-group-l.opengroup.narkive.com/lKcmfoRI/predictable-scheduling-behavior-in-pthread-cond-broadcast > > When David wrote that, multiprocessor systems were still rare and > limited to very expensive systems (e.g. Sequent) (and for the most > part, weren't running real-time code). I was on the X/Open working group for > a few years during that time period, and one of my collegues at > SGI was part of the 1003.4 working group. > > thirty years later, pthread_cond_t is heavily used by non-realtime > code, where such priority inversions (usually very transient) don't > matter. > > For the number of cases where pthread_cond_t is used in hard > real-time code, the appropriate techniques (i.e. holding the mutex > while signaling the condition) are available. > Exactly. It depends on what the programmer is trying to accomplish. Signaling inside of a mutex locked region will work regardless of priority issues, your code will work. However, _if_ your goal is not real time and/or enforcing some specific scheduling polity... Then, I would refrain from that as signalling outside of the mutex is more efficient in this case.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-17 18:37 +0000 |
| Message-ID | <20231117103650.654@kylheku.com> |
| In reply to | #117853 |
On 2023-11-17, Scott Lurndal <scott@slp53.sl.home> wrote: >>https://austin-group-l.opengroup.narkive.com/lKcmfoRI/predictable-scheduling-behavior-in-pthread-cond-broadcast > > When David wrote that, multiprocessor systems were still rare and The referenced discussion appears to be from early 2010; maybe he was reiterating something from an earlier time? -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-11-18 00:45 +0000 |
| Message-ID | <8PT5N.42131$_Oab.23742@fx15.iad> |
| In reply to | #117855 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: >On 2023-11-17, Scott Lurndal <scott@slp53.sl.home> wrote: >>>https://austin-group-l.opengroup.narkive.com/lKcmfoRI/predictable-scheduling-behavior-in-pthread-cond-broadcast >> >> When David wrote that, multiprocessor systems were still rare and > >The referenced discussion appears to be from early 2010; maybe >he was reiterating something from an earlier time? The Posix 1003.4 (.4b - realtime and .4c - threads) work was in the mid 90's. At that time, SMP systems were expensive and relatively rare. My 2p octane workstation in 1998 was great, but uncommon even in SGI engineering.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-18 02:30 +0000 |
| Message-ID | <20231117182615.499@kylheku.com> |
| In reply to | #117856 |
On 2023-11-18, Scott Lurndal <scott@slp53.sl.home> wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: >>On 2023-11-17, Scott Lurndal <scott@slp53.sl.home> wrote: >>>>https://austin-group-l.opengroup.narkive.com/lKcmfoRI/predictable-scheduling-behavior-in-pthread-cond-broadcast >>> >>> When David wrote that, multiprocessor systems were still rare and >> >>The referenced discussion appears to be from early 2010; maybe >>he was reiterating something from an earlier time? > > The Posix 1003.4 (.4b - realtime and .4c - threads) work was in the > mid 90's. At that time, SMP systems were expensive and relatively > rare. My 2p octane workstation in 1998 was great, but uncommon even > in SGI engineering. In 1995, I had a PC with a consumer-grade dual Pentium 100 ASUS motherboard, running Linux 1.3.x, FWIW. Two parallel gcc compilations were a whopping 30% faster than one! :) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web