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 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-15 12:20 -0800 |
| Message-ID | <uj396r$1spi2$1@dont-email.me> |
| In reply to | #117830 |
On 11/15/2023 12:18 PM, Chris M. Thomasson wrote: > On 11/14/2023 5:47 PM, Pavel wrote: >> Chris M. Thomasson wrote: >>> On 11/13/2023 9:28 PM, Chris M. Thomasson wrote: >>>> On 11/13/2023 7:27 PM, Kaz Kylheku wrote: >>>>> On 2023-11-14, Pavel >>>>> <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: >>>>>> "as-if" and "according to the scheduling policy (if applicable)" here >>>>>> are important. The standard intent may be to permit only the threads >>>>>> that are "unblocked" contend for the mutex -- as opposed to all >>>>>> non-blocked threads. >>>>> >>>>> It's possible that only one thread is unblocked by a >>>>> pthread_cond_signal. It takes at least two parties to contend for >>>>> something. >>>>> >>>> >>>> A signalling thread does its thing while holding the mutex... Well, >>>> it hears the following playing in the background: >>>> >>>> https://youtu.be/7YvAYIJSSZY >>> >>> A condvar that cannot signal/broadcast from outside of a held mutex >>> is broken by default. >> It can, it's just that the desired scheduling policy cannot be >> *effectively* applied if a program signal outside of that mutex. >> >> E.g. in some scenario a higher-prio thread could stay indefinitely >> starved by the lower-prio thread, regardless of the thread library >> implementation. > > Afaict, it is an implementation detail. Say, SCHED_FIFO, the impl shall > strive to honor this. If it has to use a bakery algorithm to do it, so > be it. Also, you as the programmer can choose to signal within a locked region. No problem.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-15 21:26 +0000 |
| Message-ID | <20231115122730.814@kylheku.com> |
| In reply to | #117822 |
On 2023-11-15, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
> Chris M. Thomasson wrote:
>> On 11/13/2023 9:28 PM, Chris M. Thomasson wrote:
>>> On 11/13/2023 7:27 PM, Kaz Kylheku wrote:
>>>> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>
>>>> wrote:
>>>>> "as-if" and "according to the scheduling policy (if applicable)" here
>>>>> are important. The standard intent may be to permit only the threads
>>>>> that are "unblocked" contend for the mutex -- as opposed to all
>>>>> non-blocked threads.
>>>>
>>>> It's possible that only one thread is unblocked by a
>>>> pthread_cond_signal. It takes at least two parties to contend for
>>>> something.
>>>>
>>>
>>> A signalling thread does its thing while holding the mutex... Well, it
>>> hears the following playing in the background:
>>>
>>> https://youtu.be/7YvAYIJSSZY
>>
>> A condvar that cannot signal/broadcast from outside of a held mutex is
>> broken by default.
> It can, it's just that the desired scheduling policy cannot be
> *effectively* applied if a program signal outside of that mutex.
>
> E.g. in some scenario a higher-prio thread could stay indefinitely
> starved by the lower-prio thread, regardless of the thread library
> implementation.
I don't see what difference it can actually make, other than in
situations when a thread receives a priority boost while holding a
mutex.
Only one of these is true: (1) either the pthread_cond_signal and
pthread_cond_broadcast functions transfer threads from waiting on the
condition to waiting on the mutex, or (2) they don't: threads are woken,
and have to execute an operation equivalent to pthread_mutex_lock.
(Though there is no mutex argument in the API, the thread is waiting
with respect to a particular mutex. Each thread waiting on the same
condition could nominate a different mutex. So for each thread waiting
on a condition, we know which mutex it released in doing so and can
transfer it to wait on the mutex.)
If the pthread_cond_signal function transfers a thread from the
condition to the mutex according to (1), then everything is cool with
regard to scheduling.
Whether we have this:
pthread_mutex_unlock(&m);
pthread_cond_signal(&c);
...
// re-acquire
pthread_mutex_lock(&m);
or this:
pthread_cond_signal(&c);
pthread_mutex_unlock(&m);
...
// re-acquire
pthread_mutex_lock(&m);
the most important thing is that the waiting threads are already
transferred to waiting on the mutex, before the signaling thread call
tries to re-acquire the mutex.
I.e. the woken threads always reach the mutex wait first, regardless of
these two orders of operations on the part of the signaling thread.
On the other hand, if the pthread_cond_signal operation just wakes up
the threads, such that they themselves have to call the equivalent of
pthread_mutex_lock to reacquire the mutex, we do not gain any special
guarantees in one order or the other. Under either order of the
statements, the signaling thread can snatch the mutex away from the
signaled threads, when reaching the pthread_mutex_lock call,
even if it is a low priority thread and the others are high.
Now with real-time priorities and mutexes that prevent priority
inversion, we could have the following situation:
While a low-priority thread holds a mutex, it is temporarily boosted to
the highest priority from among the set of threads waiting for that
mutex.
There we have a difference between signaling inside or outside, the
reason being that when the thread leaves the mutex to signal outside, it
loses the temporary priority boost. That could lead to an undue delay in
signaling the condition.
The statement in the POSIX standard about predictable scheduling
behavior is like recommending sleep calls to for obtaining more
predictable behavior in a program riddled with race conditions.
If I'm an implementor reading that statement, I cannot infer any
concrete requirements about what it is that I'm supposed to do in
pthread_cond_signal to bring about more predictable scheduling.
Specifications should give specific requirements, not vague opinions.
--
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 00:25 -0500 |
| Message-ID | <3Jh5N.56974$svP4.10382@fx12.iad> |
| In reply to | #117833 |
Kaz Kylheku wrote: > On 2023-11-15, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: >> Chris M. Thomasson wrote: >>> On 11/13/2023 9:28 PM, Chris M. Thomasson wrote: >>>> On 11/13/2023 7:27 PM, Kaz Kylheku wrote: >>>>> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> >>>>> wrote: >>>>>> "as-if" and "according to the scheduling policy (if applicable)" here >>>>>> are important. The standard intent may be to permit only the threads >>>>>> that are "unblocked" contend for the mutex -- as opposed to all >>>>>> non-blocked threads. >>>>> >>>>> It's possible that only one thread is unblocked by a >>>>> pthread_cond_signal. It takes at least two parties to contend for >>>>> something. >>>>> >>>> >>>> A signalling thread does its thing while holding the mutex... Well, it >>>> hears the following playing in the background: >>>> >>>> https://youtu.be/7YvAYIJSSZY >>> >>> A condvar that cannot signal/broadcast from outside of a held mutex is >>> broken by default. >> It can, it's just that the desired scheduling policy cannot be >> *effectively* applied if a program signal outside of that mutex. >> >> E.g. in some scenario a higher-prio thread could stay indefinitely >> starved by the lower-prio thread, regardless of the thread library >> implementation. > > I don't see what difference it can actually make, other than in > situations when a thread receives a priority boost while holding a > mutex. > > Only one of these is true: (1) either the pthread_cond_signal and > pthread_cond_broadcast functions transfer threads from waiting on the > condition to waiting on the mutex, or (2) they don't: threads are woken, > and have to execute an operation equivalent to pthread_mutex_lock. > > (Though there is no mutex argument in the API, the thread is waiting > with respect to a particular mutex. Each thread waiting on the same > condition could nominate a different mutex. So for each thread waiting > on a condition, we know which mutex it released in doing so and can > transfer it to wait on the mutex.) > > If the pthread_cond_signal function transfers a thread from the > condition to the mutex according to (1), then everything is cool with > regard to scheduling. > > Whether we have this: > > pthread_mutex_unlock(&m); > pthread_cond_signal(&c); > > ... > > // re-acquire > pthread_mutex_lock(&m); > > or this: > > pthread_cond_signal(&c); > > pthread_mutex_unlock(&m); > > ... > // re-acquire > pthread_mutex_lock(&m); > > the most important thing is that the waiting threads are already > transferred to waiting on the mutex, before the signaling thread call > tries to re-acquire the mutex. > > I.e. the woken threads always reach the mutex wait first, regardless of > these two orders of operations on the part of the signaling thread. > > On the other hand, if the pthread_cond_signal operation just wakes up > the threads, such that they themselves have to call the equivalent of > pthread_mutex_lock to reacquire the mutex, we do not gain any special > guarantees in one order or the other. Under either order of the > statements, the signaling thread can snatch the mutex away from the > signaled threads, when reaching the pthread_mutex_lock call, > even if it is a low priority thread and the others are high. > > Now with real-time priorities and mutexes that prevent priority > inversion, we could have the following situation: > > While a low-priority thread holds a mutex, it is temporarily boosted to > the highest priority from among the set of threads waiting for that > mutex. > > There we have a difference between signaling inside or outside, the > reason being that when the thread leaves the mutex to signal outside, it > loses the temporary priority boost. That could lead to an undue delay in > signaling the condition. > > The statement in the POSIX standard about predictable scheduling > behavior is like recommending sleep calls to for obtaining more > predictable behavior in a program riddled with race conditions. > > If I'm an implementor reading that statement, I cannot infer any > concrete requirements about what it is that I'm supposed to do in > pthread_cond_signal to bring about more predictable scheduling. > > Specifications should give specific requirements, not vague opinions. POSIX *specifies* exactly what scheduling policies a compliant implementation shall support (SCHED_OTHER, SCHED_FIFO, SCHED_RR, and SCHED_SPORADIC) and how exactly each of these shall behave. In addition to specifying the behavior, the spec *explains* the purpose of some policies so programmers would know when they were meant to be used. Explanations are there to be helpful, they are not specs. In C++ Standard, they would be formatted as a non-normative Notes. For example, SCHED_RR, under some conditions, has an effect "to ensure.. that one of them [the threads] does not monopolize the processor". To me, this is clearly an example of "predictable scheduling behavior". The spec for pthread_cond_signal and broadast further simply adds one more condition required to achieve such behavior, namely "the signalling thread owns the mutex that the waiter threads used to start waiting". If your doesn't need a predictable scheduling behavior, your app doesn't have to do that. For an implementer, this statement is actually very useful: it permits them to not ensure "predictable scheduling behavior" when the cond waiter is signaled from a thread not owning the mutex. Could this statement be thrown away? -- Yes. Would this make implementor's life easier? -- No, it would make it much harder. The implementor could be bugged by the user complaints like "Your implementation must be broken, else why my higher-prio thread is starving?". With the current spec, they could answer: "This is because the spec allows my implementation to starve your higher-prio thread to death -- or exhibit any other unpredictable scheduling behavior -- if your condvar-signalling thread does not own the mutex that the higher-prio thread used to start waiting for the condvar".
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-11-14 20:42 -0500 |
| Message-ID | <0mV4N.683$%d2c.644@fx08.iad> |
| In reply to | #117786 |
Kaz Kylheku wrote: > On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote: >> "as-if" and "according to the scheduling policy (if applicable)" here >> are important. The standard intent may be to permit only the threads >> that are "unblocked" contend for the mutex -- as opposed to all >> non-blocked threads. > > It's possible that only one thread is unblocked by a > pthread_cond_signal. It takes at least two parties to contend for > something. > My point was that the "unblocked" thread could be the thread that "won" the contention. "as-if" there meant that the threads didn't really need to be all woken up / unblocked and start contending; but the contention could be resolved according to the scheduling policy (the same one that would be applied if they were actually running and contending for the mutex, without any waiting for the condvar) within the signal call.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-28 15:32 -0800 |
| Message-ID | <uk5tb5$f83j$2@dont-email.me> |
| In reply to | #117821 |
On 11/14/2023 5:42 PM, Pavel wrote: > Kaz Kylheku wrote: >> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> >> wrote: >>> "as-if" and "according to the scheduling policy (if applicable)" here >>> are important. The standard intent may be to permit only the threads >>> that are "unblocked" contend for the mutex -- as opposed to all >>> non-blocked threads. >> >> It's possible that only one thread is unblocked by a >> pthread_cond_signal. It takes at least two parties to contend for >> something. >> > My point was that the "unblocked" thread could be the thread that "won" > the contention. "as-if" there meant that the threads didn't really need > to be all woken up / unblocked and start contending; but the contention > could be resolved according to the scheduling policy (the same one that > would be applied if they were actually running and contending for the > mutex, without any waiting for the condvar) within the signal call. The flexibility of the API allows us to signal inside and/or outside of a locked mutex region. So, whats the problem?
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-11-12 19:17 -0500 |
| Message-ID | <oWd4N.9246$Wzw6.5120@fx13.iad> |
| In reply to | #117760 |
Bonita Montero wrote:
> Am 11.11.2023 um 23:45 schrieb Pavel:
>> Bonita Montero wrote:
>>> Am 09.11.2023 um 05:42 schrieb Chris M. Thomasson:
>>>> On 11/8/2023 8:38 PM, Bonita Montero wrote:
>>>>> Am 09.11.2023 um 05:36 schrieb Chris M. Thomasson:
>>>>>
>>>>>> Humm... Are you okay Bonita? Anything wrong with you?
>>>>>
>>>>> Hoare monitors relase a waiting thread immediately after a notify()
>>>>> and that's less efficient.
>>>
>>>> Yawn.
>>>
>>> Re-acquiring the mutex part of a monitor after notify()
>> is exactly what Java does -- and it does it for reason.
>
> No, Java and .net keep holding the mutex while doing a notify().
Don't change the subject. Java releases lock *on waiting thread* (which
is the behavior of a Hoare monitor by design) while waiting and then
reacquires it after it was notified.
RTFM for once (although, I know you won't):
"
public final void wait()
throws InterruptedException
Causes the current thread to wait until another thread invokes the
notify() method or the notifyAll() method for this object. In other
words, this method behaves exactly as if it simply performs the call
wait(0).
The current thread must own this object's monitor. The thread releases
ownership of this monitor and waits until another thread notifies
threads waiting on this object's monitor to wake up either through a
call to the notify method or the notifyAll method. The thread then waits
until it can re-obtain ownership of the monitor and resumes execution.
"
> That's called a Mesa monitor.
>
>>> is an superfluous extra part that takes CPU time.
>>
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-09 05:17 +0000 |
| Message-ID | <20231108210852.275@kylheku.com> |
| In reply to | #117673 |
On 2023-11-09, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 09.11.2023 um 00:25 schrieb Kaz Kylheku: > >> Spurious wakesup are part of the "Mesa semantics" of monitors >> and condition variables, in contrast to the "Hoare semantics". > > Hoare monitors suck since they are less efficient. Hoare gave us the concept of monitors and condition variables, which deserves respect. The original variant is semantically useful; the guarantees that it provides can make it easier to reason about correctness. It's something to know about as part of a well-rounded education in concurrent programming. -- 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-08 21:18 -0800 |
| Message-ID | <uihq3d$228mv$4@dont-email.me> |
| In reply to | #117697 |
On 11/8/2023 9:17 PM, Kaz Kylheku wrote: > On 2023-11-09, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 09.11.2023 um 00:25 schrieb Kaz Kylheku: >> >>> Spurious wakesup are part of the "Mesa semantics" of monitors >>> and condition variables, in contrast to the "Hoare semantics". >> >> Hoare monitors suck since they are less efficient. > > Hoare gave us the concept of monitors and condition variables, > which deserves respect. > > The original variant is semantically useful; the guarantees that it > provides can make it easier to reason about correctness. > > It's something to know about as part of a well-rounded education > in concurrent programming. > I concur with that assessment.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-08 21:20 -0800 |
| Message-ID | <uihq6f$228mv$5@dont-email.me> |
| In reply to | #117699 |
On 11/8/2023 9:18 PM, Chris M. Thomasson wrote: > On 11/8/2023 9:17 PM, Kaz Kylheku wrote: >> On 2023-11-09, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 09.11.2023 um 00:25 schrieb Kaz Kylheku: >>> >>>> Spurious wakesup are part of the "Mesa semantics" of monitors >>>> and condition variables, in contrast to the "Hoare semantics". >>> >>> Hoare monitors suck since they are less efficient. >> >> Hoare gave us the concept of monitors and condition variables, >> which deserves respect. >> >> The original variant is semantically useful; the guarantees that it >> provides can make it easier to reason about correctness. >> >> It's something to know about as part of a well-rounded education >> in concurrent programming. >> > > I concur with that assessment. I wonder if Bontia is pushing things to a borderline. Heck, he/she is almost making me want to work on it!!! https://youtu.be/rSaC-YbSDpo
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-11-09 06:19 +0100 |
| Message-ID | <uihq5s$22aps$1@raubtier-asyl.eternal-september.org> |
| In reply to | #117697 |
Am 09.11.2023 um 06:17 schrieb Kaz Kylheku: > Hoare gave us the concept of monitors and condition variables, > which deserves respect. Hoare monitors are less efficient since they give up ownership of the mutex part while notifying. That are two kernel calls which could be prevented.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-08 21:20 -0800 |
| Message-ID | <uihq7g$228mv$6@dont-email.me> |
| In reply to | #117700 |
On 11/8/2023 9:19 PM, Bonita Montero wrote: > Am 09.11.2023 um 06:17 schrieb Kaz Kylheku: > >> Hoare gave us the concept of monitors and condition variables, >> which deserves respect. > > Hoare monitors are less efficient since they give up ownership > of the mutex part while notifying. That are two kernel calls > which could be prevented. Avoiding Kernel calls is great.com.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-08 23:51 +0000 |
| Message-ID | <20231108154733.223@kylheku.com> |
| In reply to | #117663 |
On 2023-11-08, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > On 11/8/2023 11:56 AM, Bonita Montero wrote: >> I've implemented a monitor without spurious wakeups. > > Yawn. Funnier: Amine Moulay Ramdane has written seven, likewise dead in the water. -- 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-08 21:10 -0800 |
| Message-ID | <uihpkh$2262f$1@dont-email.me> |
| In reply to | #117670 |
On 11/8/2023 3:51 PM, Kaz Kylheku wrote: > On 2023-11-08, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 11/8/2023 11:56 AM, Bonita Montero wrote: >>> I've implemented a monitor without spurious wakeups. >> >> Yawn. > > Funnier: > > Amine Moulay Ramdane has written seven, likewise dead in the water. > Actually, Amine had a couple of interesting ideas from years ago. Therefore, I think that Amine just might be "smarter" than Bonita? Still, wrt Anime, not sure if the ideas are original or from reading a white paper.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-08 15:32 -0800 |
| Message-ID | <uih5r1$1rd03$1@dont-email.me> |
| In reply to | #117663 |
On 11/8/2023 11:56 AM, Bonita Montero wrote: > Am 08.11.2023 um 20:49 schrieb Kaz Kylheku: > >> No, the "monitor" idea you're proposing is different in this >> way. > > That's not true. That spurious wakesups may happen with a mutex and > a condition variable are constituted in that both are separate enti- > ties. Spuriuos wakesups never happen with my implementation, but > stolen wakeups are still possible. > >> Monitors as they are understood in computer science (first described by >> C. A. R. Hoare) do not combine the monitor and condition variables into >> one object; they are distinct entities: one monitor, zero to many >> conditions. mutex and condition variables happen to be intimately interconnected. Look up wait morphing... > > The way monitors work does not suggest an implementation, or they can > be based internally on a mutex and a condition variable, but if you > have a monitor that never has spurious wakeups, it is implemented > like mine. > >> To avoid muddying the debate with nonstandard terminology, you might >> want to call your cockamamie idea "bonitor". > > I've implemented a monitor without spurious wakeups. >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-11-09 05:35 +0100 |
| Message-ID | <uihnhu$21tq7$2@raubtier-asyl.eternal-september.org> |
| In reply to | #117671 |
Am 09.11.2023 um 00:32 schrieb Chris M. Thomasson: > mutex and condition variables happen to be intimately interconnected. > Look up wait morphing... With my implementation registering as a thread wanting to enter the mutex and waiting to be notified is one atomic step. That's only possible if they're one part.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-08 21:17 -0800 |
| Message-ID | <uihq1s$228mv$3@dont-email.me> |
| In reply to | #117675 |
On 11/8/2023 8:35 PM, Bonita Montero wrote: > Am 09.11.2023 um 00:32 schrieb Chris M. Thomasson: > >> mutex and condition variables happen to be intimately interconnected. >> Look up wait morphing... > > With my implementation registering as a thread wanting to enter the > mutex and waiting to be notified is one atomic step. That's only > possible if they're one part. > Humm... Sounds good. However, I need to try it out. Also, if you don't mind I might actually model it in relacy.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-11-09 06:22 +0100 |
| Message-ID | <uihqac$22aps$2@raubtier-asyl.eternal-september.org> |
| In reply to | #117698 |
Am 09.11.2023 um 06:17 schrieb Chris M. Thomasson: > Humm... Sounds good. However, I need to try it out. Also, if you don't > mind I might actually model it in relacy. I've witten my own unit test. The Win32 code worked immediately, but the SysV-code didn't work immediately also because I forgot to have IPC_NOWAIT while releasing a semaphore. Why is there a way to wait for the release of a mutex to be accepted by another thread ? Who comes up with that ?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-08 21:27 -0800 |
| Message-ID | <uihqkv$228mv$7@dont-email.me> |
| In reply to | #117703 |
On 11/8/2023 9:22 PM, Bonita Montero wrote: > Am 09.11.2023 um 06:17 schrieb Chris M. Thomasson: > >> Humm... Sounds good. However, I need to try it out. Also, if you don't >> mind I might actually model it in relacy. > > I've witten my own unit test. The Win32 code worked immediately, > but the SysV-code didn't work immediately also because I forgot > to have IPC_NOWAIT while releasing a semaphore. Why is there a > way to wait for the release of a mutex to be accepted by another > thread ? Who comes up with that ? Well, invvvho, it might be prudent of me to model it in Relacy. The act of me porting your work over into its logic base is going to get me really intimate with your code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-11-09 06:29 +0100 |
| Message-ID | <uihqo7$22dbg$1@raubtier-asyl.eternal-september.org> |
| In reply to | #117704 |
Am 09.11.2023 um 06:27 schrieb Chris M. Thomasson: > Well, invvvho, it might be prudent of me to model it in Relacy. > The act of me porting your work over into its logic base is > going to get me really intimate with your code. Just reading the code is easier.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-08 21:31 -0800 |
| Message-ID | <uihqqq$228mv$9@dont-email.me> |
| In reply to | #117705 |
On 11/8/2023 9:29 PM, Bonita Montero wrote: > Am 09.11.2023 um 06:27 schrieb Chris M. Thomasson: > >> Well, invvvho, it might be prudent of me to model it in Relacy. >> The act of me porting your work over into its logic base is >> going to get me really intimate with your code. > > Just reading the code is easier. Yup. Porting your code to Relacy is going to force me to read every damn line of your code. So, touche?
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web