Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #91550 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2023-09-06 20:15 +0200 |
| Last post | 2023-10-04 18:04 +0200 |
| Articles | 20 on this page of 665 — 15 participants |
Back to article view | Back to comp.lang.c++
Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-06 20:15 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-06 18:44 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 04:54 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-07 00:18 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 06:27 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-07 10:44 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 18:39 +0200
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:27 +0000
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-07 11:06 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-07 12:20 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-07 12:52 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-07 12:58 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-07 13:31 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-08 13:20 -0700
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:13 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 12:35 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 20:24 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-07 20:53 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-08 07:37 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-08 14:54 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-09 05:44 +0200
Re: Thread-safe initialization of static objects Paavo Helde <eesnimi@osa.pri.ee> - 2023-09-09 17:54 +0300
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-09 19:26 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-09 13:42 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-09 21:15 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-09 13:37 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-10 10:57 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-10 06:51 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-10 17:46 +0200
Re: Thread-safe initialization of static objects Paavo Helde <eesnimi@osa.pri.ee> - 2023-09-10 19:08 +0300
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-10 18:15 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 11:13 -0700
Re: Thread-safe initialization of static objects Paavo Helde <eesnimi@osa.pri.ee> - 2023-09-10 21:38 +0300
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-11 04:02 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-10 20:33 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 21:50 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-11 15:44 +0200
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-11 15:49 +0200
Re: Thread-safe initialization of static objects Paavo Helde <eesnimi@osa.pri.ee> - 2023-09-11 18:20 +0300
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-11 18:34 +0200
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-16 17:06 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-20 01:14 -0700
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-20 13:32 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 11:51 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-10 09:32 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 11:14 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-10 18:50 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 21:42 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-11 23:58 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 14:02 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-18 20:11 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 11:12 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-10 18:05 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 11:49 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-09 21:17 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 12:20 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-09 21:55 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 12:59 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 13:00 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-10 10:58 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 11:05 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 11:08 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 12:21 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-09 13:41 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-10 10:59 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 11:09 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 11:12 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-11 16:29 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-11 12:41 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-12 04:28 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-11 22:39 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-12 11:44 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-12 11:33 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-12 20:43 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-12 15:55 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-12 15:56 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-13 11:53 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-13 16:23 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-14 11:10 +0200
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-14 14:37 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-14 16:52 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-15 21:39 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-16 10:03 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-16 05:41 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-16 16:07 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-16 13:23 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-16 19:38 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-16 11:46 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 05:45 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:25 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:30 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:42 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:44 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:50 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:52 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 12:01 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 21:12 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 12:57 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 07:05 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:21 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 05:08 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 22:01 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 10:43 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:30 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-20 05:33 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 20:49 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 22:16 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:51 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-17 19:20 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 21:29 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-17 19:36 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 07:06 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 17:30 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 19:36 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-18 20:15 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 05:10 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 22:01 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 10:46 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 02:08 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 11:36 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-19 07:48 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 14:11 +0200
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 15:41 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 16:41 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 19:50 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:06 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-19 18:42 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-20 05:38 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 20:50 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-20 07:53 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:03 -0700
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-19 13:49 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 16:14 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:07 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-19 18:45 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 15:50 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-20 05:35 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 21:01 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-20 07:54 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-20 15:18 +0200
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-20 14:20 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-20 16:31 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 11:53 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-20 22:23 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 18:46 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 18:56 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 19:07 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 19:11 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-20 09:48 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 11:54 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-20 12:36 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-20 14:02 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 21:12 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-21 04:46 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 21:52 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-21 01:23 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 21:13 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-21 01:04 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:13 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 05:41 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-20 18:46 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 05:42 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 21:24 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 09:47 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:19 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 04:28 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-21 23:14 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 06:39 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-22 07:31 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 14:15 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-22 18:31 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-23 06:38 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 23:12 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-23 09:40 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 11:39 -0700
Re: Thread-safe initialization of static objects Daniel <danielaparker@gmail.com> - 2023-09-24 05:57 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-21 07:36 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 14:40 +0200
Re: Thread-safe initialization of static objects David Brown <david.brown@hesbynett.no> - 2023-09-21 15:05 +0200
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 16:17 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:25 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 04:29 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 17:18 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-21 07:48 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 17:03 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:27 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:21 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-21 18:42 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 23:21 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 15:28 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 15:31 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 04:29 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 17:21 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 21:09 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-19 09:55 -0700
Re: Thread-safe initialization of static objects Paavo Helde <eesnimi@osa.pri.ee> - 2023-09-19 21:11 +0300
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 20:59 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:12 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-20 05:35 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 21:01 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-19 18:47 -0400
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-20 20:22 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 09:58 +0200
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 10:03 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-21 07:42 -0400
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-21 14:54 +0000
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-21 22:25 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 06:40 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-22 07:30 -0400
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-22 04:58 -0700
Re: Thread-safe initialization of static objects David Brown <david.brown@hesbynett.no> - 2023-09-22 16:27 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 10:41 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 19:50 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 17:24 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-22 21:58 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 20:33 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-21 01:38 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 11:02 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-21 02:59 -0700
Re: Thread-safe initialization of static objects David Brown <david.brown@hesbynett.no> - 2023-09-21 13:19 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-21 05:01 -0700
Re: Thread-safe initialization of static objects David Brown <david.brown@hesbynett.no> - 2023-09-21 15:03 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-21 07:30 -0700
Re: Thread-safe initialization of static objects David Brown <david.brown@hesbynett.no> - 2023-09-21 20:10 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-21 18:39 +0000
Re: Thread-safe initialization of static objects David Brown <david.brown@hesbynett.no> - 2023-09-22 12:35 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-21 14:44 -0700
Re: Thread-safe initialization of static objects David Brown <david.brown@hesbynett.no> - 2023-09-22 13:05 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-22 04:50 -0700
Re: Thread-safe initialization of static objects David Brown <david.brown@hesbynett.no> - 2023-09-22 17:01 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:41 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 14:37 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:43 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:40 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 14:34 +0200
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-21 14:56 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 17:04 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:56 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:38 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 04:30 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 10:37 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-21 22:21 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 04:31 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 10:39 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-22 22:15 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 20:22 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:21 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-17 15:47 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 07:07 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 17:34 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 19:43 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:23 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:22 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 05:11 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 22:02 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-21 22:50 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 06:41 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-22 05:15 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 08:52 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 10:30 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 19:35 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-22 18:14 +0000
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-22 03:03 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-22 22:23 -0400
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-17 19:49 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 07:16 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 17:53 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 20:08 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 18:15 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:26 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:25 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 13:02 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-16 16:34 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 05:57 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-17 10:46 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 18:02 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-17 13:40 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:04 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-17 14:26 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:32 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-17 14:35 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:46 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:43 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:27 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-17 18:49 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:51 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:53 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:59 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 13:23 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 07:09 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:38 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-17 19:22 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:39 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-17 15:50 -0400
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-17 13:37 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:06 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:27 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:43 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:48 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-17 15:41 -0400
Re: Thread-safe initialization of static objects Paavo Helde <eesnimi@osa.pri.ee> - 2023-09-18 00:29 +0300
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 07:18 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-18 08:13 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 14:37 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-18 21:04 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 05:14 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 22:06 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 18:07 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 20:14 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 19:42 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 05:16 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 04:05 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 22:08 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 22:11 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 05:50 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 23:19 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 23:20 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 07:59 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 10:49 +0200
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 10:47 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 16:53 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 19:53 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:17 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-20 05:36 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 21:08 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-20 05:37 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-20 03:52 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 21:03 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 12:36 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-20 21:09 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 14:15 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 05:46 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 21:25 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 09:51 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:34 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 04:32 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-21 21:18 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 04:33 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:56 -0700
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-18 14:59 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 17:19 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:57 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:49 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-17 14:37 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-17 20:49 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-17 11:52 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-17 15:43 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 07:18 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-18 08:11 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 14:45 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 13:01 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 13:01 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-17 16:11 -0400
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-17 16:01 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-18 07:20 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 12:48 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-18 20:30 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 05:17 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 22:14 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-19 10:50 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-21 11:29 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-20 20:42 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-21 09:49 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-21 22:58 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 06:44 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-22 05:34 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 08:54 +0200
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-22 17:56 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-22 20:12 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-22 18:38 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-23 06:41 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 22:59 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-23 08:34 +0200
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-23 08:35 +0200
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-23 10:44 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-23 11:20 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-23 14:23 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 11:38 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 11:53 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-24 02:22 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 19:59 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 20:08 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 10:08 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-24 07:15 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 13:33 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-24 08:01 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 14:10 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-24 12:47 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-25 01:10 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-24 21:15 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-25 10:00 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-25 07:15 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-25 14:43 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-25 19:29 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 06:36 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 04:52 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 11:11 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-26 07:23 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 14:36 +0200
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-26 15:23 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 17:31 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 13:02 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-26 18:38 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 13:04 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-26 07:23 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 14:37 +0200
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-26 15:24 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 17:33 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 13:07 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-26 18:40 -0400
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-28 21:46 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 14:02 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-29 23:57 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-30 08:07 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-30 14:06 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-01 07:00 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-10-01 13:18 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-01 21:03 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-10-01 15:45 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-02 05:50 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-10-02 07:56 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-02 14:00 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-10-02 08:04 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-02 15:44 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-02 12:18 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-01 19:19 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-02 05:51 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-02 22:24 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-02 19:39 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-02 23:30 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-02 21:24 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-03 06:19 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-04 22:03 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-05 04:40 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-10-05 07:56 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-05 12:19 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-05 21:29 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-08 06:54 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-13 22:51 -0400
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-30 19:07 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-30 12:30 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-30 12:32 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-30 12:49 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-30 13:24 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-30 21:09 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-30 20:52 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-01 07:01 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-01 16:41 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-01 19:00 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-01 17:04 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 13:06 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-27 14:48 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 15:11 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-28 20:56 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 15:15 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-27 15:25 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 15:56 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 15:20 -0700
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-27 22:37 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 15:49 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-27 15:59 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 16:06 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-27 16:10 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 16:15 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-27 22:27 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 15:57 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-27 16:38 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-28 04:07 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-28 13:24 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-28 04:46 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-28 14:46 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-28 06:09 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-28 14:34 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 14:03 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-29 05:07 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 14:15 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-29 05:37 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 16:35 +0200
Re: Thread-safe initialization of static objects Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 08:03 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 17:08 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 11:44 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 20:54 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 11:57 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 12:00 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 21:09 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 12:26 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 12:27 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 21:31 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 12:34 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 21:37 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 12:41 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 21:30 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 12:36 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 12:38 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 21:43 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 13:09 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 22:14 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 13:28 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-29 20:44 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-30 11:15 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-30 15:51 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-30 18:04 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-30 17:05 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-30 19:26 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-30 14:56 -0400
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-30 19:10 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-30 12:24 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-07 22:17 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 12:45 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-28 18:30 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 16:46 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 18:54 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-28 21:20 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-28 18:38 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 20:47 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 10:50 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-25 21:53 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 21:01 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-28 21:22 -0400
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-25 21:51 -0400
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-24 12:46 -0400
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-24 17:04 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 22:52 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 23:08 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-26 09:05 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 12:58 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-26 13:58 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 14:06 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 14:07 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 14:11 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 14:17 -0700
Re: Thread-safe initialization of static objects Michael Fisher <michaelsfishers61@gmail.com> - 2023-09-26 14:40 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 11:34 -0700
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-22 22:22 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-22 17:44 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-23 06:42 +0200
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-23 15:00 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-23 17:23 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 20:05 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 10:09 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-24 02:50 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 12:05 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 11:41 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 11:49 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 12:08 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-25 10:20 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 19:27 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-27 00:36 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 14:12 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-25 10:15 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 10:49 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 10:53 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-24 07:18 -0400
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-24 04:18 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 13:34 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-24 04:50 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 13:55 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 11:42 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-24 08:04 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 14:13 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-24 05:21 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 14:35 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-24 05:47 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 14:51 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 11:50 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-24 21:18 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-25 10:02 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-25 07:15 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-25 18:11 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 10:47 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-25 18:08 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 15:07 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-25 19:29 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-28 20:34 -0700
Re: Thread-safe initialization of static objects James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-24 12:27 -0400
Re: Thread-safe initialization of static objects James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-24 17:19 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 14:32 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-24 19:00 -0400
Re: Thread-safe initialization of static objects James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-24 19:35 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 18:43 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-24 12:53 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 11:36 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-22 22:50 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-23 06:44 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-23 17:58 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 19:00 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-24 12:59 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 11:45 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 19:03 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-24 13:00 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 11:43 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-24 04:10 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-23 19:19 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-24 13:10 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-25 01:06 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 18:45 -0700
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-25 15:51 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-25 18:21 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-28 18:50 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-25 21:47 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 10:34 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-26 07:42 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 14:33 +0200
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-26 15:25 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 17:30 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-26 08:52 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 18:08 +0200
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-26 10:00 -0700
Re: Thread-safe initialization of static objects Michael S <already5chosen@yahoo.com> - 2023-09-26 10:04 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 19:30 +0200
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-26 21:32 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 19:17 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 17:09 +0000
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-26 19:33 +0200
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 23:16 +0000
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-26 21:10 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 19:17 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-28 21:40 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-28 18:48 -0700
Re: Thread-safe initialization of static objects Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 17:01 +0000
Re: Thread-safe initialization of static objects scott@slp53.sl.home (Scott Lurndal) - 2023-09-26 17:13 +0000
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 13:21 -0700
Re: Thread-safe initialization of static objects Richard Damon <Richard@Damon-Family.org> - 2023-09-26 20:45 -0400
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-28 21:38 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 11:48 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-08 13:29 -0700
Re: Thread-safe initialization of static objects Marcel Mueller <news.5.maazl@spamgourmet.org> - 2023-09-08 18:55 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-08 13:26 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-06 23:33 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 08:53 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-07 00:16 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 14:17 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-07 12:06 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 21:27 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-07 12:41 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 22:00 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-08 13:26 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-08 20:14 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-08 18:05 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-08 18:10 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-09 14:00 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 11:41 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 19:30 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-10 17:58 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 20:48 -0700
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-09 13:44 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 11:39 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-09 05:26 +0200
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 11:45 -0700
Re: Thread-safe initialization of static objects Paavo Helde <eesnimi@osa.pri.ee> - 2023-09-07 12:55 +0300
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-08 18:22 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-08 18:45 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 12:49 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-09 12:53 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-24 20:18 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 00:06 -0700
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-29 13:30 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-29 23:32 +0200
Re: Thread-safe initialization of static objects Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2023-10-02 04:39 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-02 13:54 +0200
Re: Thread-safe initialization of static objects Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-02 22:28 -0400
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-03 11:04 +0200
Re: Thread-safe initialization of static objects James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-03 23:28 -0400
Re: Thread-safe initialization of static objects "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-03 20:38 -0700
Re: Thread-safe initialization of static objects Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-04 18:04 +0200
Page 3 of 34 — ← Prev page 1 2 [3] 4 5 … 34 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-16 17:06 +0200 |
| Message-ID | <ue4g9l$3s8j6$1@dont-email.me> |
| In reply to | #91690 |
Am 11.09.2023 um 17:20 schrieb Paavo Helde: > Good, finally some code! Alas, this is not very relevant as it demoes a > local static object, my post which you replied to started with "Dynamic > initialization of a non-local variable with static storage duration..." One thing just occurred to me: with global objects, the initialization could theoretically be carried out with a delay, and this would then happen in the functional context. This would primarily solve the static initialization order fiasco. Maybe C++ could introduce an [[attribute]] for that for global objects.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-09-20 01:14 -0700 |
| Message-ID | <1bbc625d-fdc8-4e45-8659-4270ecf897d2n@googlegroups.com> |
| In reply to | #91654 |
On Sunday, September 10, 2023 at 7:09:11 PM UTC+3, Paavo Helde wrote: > 10.09.2023 18:46 Bonita Montero kirjutas: > > Am 10.09.2023 um 15:51 schrieb Richard Damon: > > > >> You don't seem to understand that sincd it CAN be done in a way that > >> always works, ... > > > > A standard shouldn't mandate that this never fails. > So suppose the standard committee agrees with you and adds a sentence to > the standard: > > Dynamic initialization of a non-local variable with static storage > duration can fail even if its initializing function does not throw, in > which case the behavior is ...undefined... / ..unspecified... / > ...calling std::terminate() after unspecified time... > > Which variant do you prefer? And how would this help the programmer who > needs to write programs in C++? Should they just avoid creating any > static variables at all, in order to not trigger this failure scenario? Avoidance of creation of function-scope static variables with non-trivial constructors is a good guiding principle. Especially so in multithreaded environment. Of course, it is a good guiding principle for more important reasons than one mentioned here.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-20 13:32 +0000 |
| Message-ID | <IvCOM.31622$2ph4.7988@fx14.iad> |
| In reply to | #91885 |
Michael S <already5chosen@yahoo.com> writes: >On Sunday, September 10, 2023 at 7:09:11=E2=80=AFPM UTC+3, Paavo Helde wrot= >e: >> 10.09.2023 18:46 Bonita Montero kirjutas:=20 >> > Am 10.09.2023 um 15:51 schrieb Richard Damon:=20 >> >=20 >> >> You don't seem to understand that sincd it CAN be done in a way that= >=20 >> >> always works, ...=20 >> >=20 >> > A standard shouldn't mandate that this never fails. >> So suppose the standard committee agrees with you and adds a sentence to= >=20 >> the standard:=20 >>=20 >> Dynamic initialization of a non-local variable with static storage=20 >> duration can fail even if its initializing function does not throw, in=20 >> which case the behavior is ...undefined... / ..unspecified... /=20 >> ...calling std::terminate() after unspecified time...=20 >>=20 >> Which variant do you prefer? And how would this help the programmer who= >=20 >> needs to write programs in C++? Should they just avoid creating any=20 >> static variables at all, in order to not trigger this failure scenario? > >Avoidance of creation of function-scope static variables with non-trivial >constructors is a good guiding principle. Especially so in multithreaded >environment. >Of course, it is a good guiding principle for more important reasons than >one mentioned here. Finally. That's indeed the case.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-20 11:51 -0700 |
| Message-ID | <ueff0f$32ncr$1@dont-email.me> |
| In reply to | #91885 |
On 9/20/2023 1:14 AM, Michael S wrote: > On Sunday, September 10, 2023 at 7:09:11 PM UTC+3, Paavo Helde wrote: >> 10.09.2023 18:46 Bonita Montero kirjutas: >>> Am 10.09.2023 um 15:51 schrieb Richard Damon: >>> >>>> You don't seem to understand that sincd it CAN be done in a way that >>>> always works, ... >>> >>> A standard shouldn't mandate that this never fails. >> So suppose the standard committee agrees with you and adds a sentence to >> the standard: >> >> Dynamic initialization of a non-local variable with static storage >> duration can fail even if its initializing function does not throw, in >> which case the behavior is ...undefined... / ..unspecified... / >> ...calling std::terminate() after unspecified time... >> >> Which variant do you prefer? And how would this help the programmer who >> needs to write programs in C++? Should they just avoid creating any >> static variables at all, in order to not trigger this failure scenario? > > Avoidance of creation of function-scope static variables with non-trivial > constructors is a good guiding principle. Especially so in multithreaded > environment. > Of course, it is a good guiding principle for more important reasons than > one mentioned here. You got it!!!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-10 09:32 -0700 |
| Message-ID | <vcmLM.868787$U3w1.456645@fx09.iad> |
| In reply to | #91652 |
On 9/10/23 8:46 AM, Bonita Montero wrote: > Am 10.09.2023 um 15:51 schrieb Richard Damon: > >> You don't seem to understand that sincd it CAN be done in a way that >> always works, ... > > A standard shouldn't mandate that this never fails. You WANT a standard that says even if your program is written totally correct, the implementation can decide that it will just make it run wrong? > >> Static Initialization has DEFINED behavior, and that behavior must be >> honored, and the implementation do what is need to make that happen. > > Locking-errors while static initialitation are unspecified; whether > they might occur or not on a specific operating system doesn't matter. > Since it has been shown that with a simpler locking method, you can ALWAYS succeed (or die with a resource error before starting user code), not meeting the requirement is just an error in the implementation. PERIOD. ANY operating system that can correctly run multi-threaded code can handle that. If it can't, it can't actually handle multi-threaded code. If an "optimization" can cause failures that can't otherwise occur, and are not allowed by the standard, then that "optimization" isn't allowed (except by switching to a non-conforming mode). You don't seem to understand what a "Standard" is.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-10 11:14 -0700 |
| Message-ID | <udl11l$lp5v$7@dont-email.me> |
| In reply to | #91657 |
On 9/10/2023 9:32 AM, Richard Damon wrote: > On 9/10/23 8:46 AM, Bonita Montero wrote: >> Am 10.09.2023 um 15:51 schrieb Richard Damon: >> >>> You don't seem to understand that sincd it CAN be done in a way that >>> always works, ... >> >> A standard shouldn't mandate that this never fails. > > You WANT a standard that says even if your program is written totally > correct, the implementation can decide that it will just make it run wrong? > >> >>> Static Initialization has DEFINED behavior, and that behavior must be >>> honored, and the implementation do what is need to make that happen. >> >> Locking-errors while static initialitation are unspecified; whether >> they might occur or not on a specific operating system doesn't matter. >> > > Since it has been shown that with a simpler locking method, you can > ALWAYS succeed (or die with a resource error before starting user code), > not meeting the requirement is just an error in the implementation. > > PERIOD. > > ANY operating system that can correctly run multi-threaded code can > handle that. If it can't, it can't actually handle multi-threaded code. > > If an "optimization" can cause failures that can't otherwise occur, and > are not allowed by the standard, then that "optimization" isn't allowed > (except by switching to a non-conforming mode). > > > You don't seem to understand what a "Standard" is. Ditto.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-10 18:50 -0400 |
| Message-ID | <fLrLM.1141591$mPI2.986632@fx15.iad> |
| In reply to | #91649 |
Richard Damon wrote: > On 9/10/23 1:57 AM, Bonita Montero wrote: >> Am 09.09.2023 um 22:37 schrieb Richard Damon: >> >>> The Standard defines the final results that must happen >>> (or possibilities that can happen in some cases). >> >> The standards also should consider side effects as in this example >> when a static initialization would fail because of a synchronization >> error. >> > You don't seem to understand that sincd it CAN be done in a way that > always works, any method that doesn't always work is just WRONG and > non-conforming. > > I guess you think that 1 + 1 must be allowed to be 1 in case of > "synchronization errors". > > Static Initialization has DEFINED behavior, and that behavior must be > honored, and the implementation do what is need to make that happen. > > Methods have been shown to do it (perhaps less performant than this is > some conditions), Actually, I think there should be always a better-performing method to implement C++ static initialization than using windows or pthread mutex -- e.g. using a specialized control like those used for call_once implementation -- at least on UNIX or Windows. This is because IMHO mutex API is a textbook case of feature bloat on both platforms. E.g. in standard UNIX (former POSIX), you can have recursive / robust / shared / errorcheck mutex (not all mutually exclusive) and who knows what else. pthread_mutex_lock shall be able to deal with either combination and the feature-check code makes (at least the current) implementation quite messy, with multiple dispatches on the same condition. On Windows, the number of options is less; but, to compensate for that :-), a mutex is always recursive plus wait functions have to know how to deal with inter-process mutexes because any handle passed to them can turn out to be of an inter-process mutex (or even not a mutex at all). Therefore, I do not think their use for static initialization (that does not require either recursive or inter-process lock) even could be optimal. > so it is possible, so you can't say the Standard is > asking for impossible behavior, thus any "optimizations" that don't meet > that defined behavior are just WRONG. > > Saying something wrong must be made right is just WRONG, so you are > WRONG in your claim. > > PERIOD.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-10 21:42 -0700 |
| Message-ID | <udm5rf$u6g6$1@dont-email.me> |
| In reply to | #91669 |
On 9/10/2023 3:50 PM, Pavel wrote:
> Richard Damon wrote:
>> On 9/10/23 1:57 AM, Bonita Montero wrote:
>>> Am 09.09.2023 um 22:37 schrieb Richard Damon:
>>>
>>>> The Standard defines the final results that must happen
>>>> (or possibilities that can happen in some cases).
>>>
>>> The standards also should consider side effects as in this example
>>> when a static initialization would fail because of a synchronization
>>> error.
>>>
>> You don't seem to understand that sincd it CAN be done in a way that
>> always works, any method that doesn't always work is just WRONG and
>> non-conforming.
>>
>> I guess you think that 1 + 1 must be allowed to be 1 in case of
>> "synchronization errors".
>>
>> Static Initialization has DEFINED behavior, and that behavior must be
>> honored, and the implementation do what is need to make that happen.
>>
>> Methods have been shown to do it (perhaps less performant than this is
>> some conditions),
> Actually, I think there should be always a better-performing method to
> implement C++ static initialization than using windows or pthread mutex
> -- e.g. using a specialized control like those used for call_once
> implementation -- at least on UNIX or Windows.
>
> This is because IMHO mutex API is a textbook case of feature bloat on
> both platforms.
>
> E.g. in standard UNIX (former POSIX), you can have recursive / robust /
> shared / errorcheck mutex (not all mutually exclusive) and who knows
> what else. pthread_mutex_lock shall be able to deal with either
> combination and the feature-check code makes (at least the current)
> implementation quite messy, with multiple dispatches on the same condition.
>
> On Windows, the number of options is less; but, to compensate for that
> :-), a mutex is always recursive plus wait functions have to know how to
> deal with inter-process mutexes because any handle passed to them can
> turn out to be of an inter-process mutex (or even not a mutex at all).
> Therefore, I do not think their use for static initialization (that does
> not require either recursive or inter-process lock) even could be optimal.
I might be missing your point here. Humm... Even though POSIX has all of
these different types of mutexs, we can use them by organization. So,
wrt windows, an intra-process mutex can be a CRITICAL_SECTION. Or an
inter-process as a mutex HANDLE.
https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexexa
Wrt the inter-process route we may need to deal with WAIT_ABANDONED, or
EOWNERDEAD wrt POSIX. So we create different types:
struct intra_process_mutex
{
CRITICAL_SECTION m_os_lock;
};
struct inter_process_mutex
{
HANDLE m_os_lock;
};
struct inter_process_mutex_robust
{
HANDLE m_os_lock;
};
These simple types can be rather easy to reason about. Wrt POSIX, the
different types would be:
struct intra_process_mutex
{
pthread_mutex_t m_os_lock;
};
struct inter_process_mutex
{
pthread_mutex_t m_os_lock;
};
struct inter_process_mutex_robust
{
pthread_mutex_t m_os_lock;
};
The point is trying to organize things a bit here.
Sound somewhat decent?
>
>> so it is possible, so you can't say the Standard is asking for
>> impossible behavior, thus any "optimizations" that don't meet that
>> defined behavior are just WRONG.
>>
>> Saying something wrong must be made right is just WRONG, so you are
>> WRONG in your claim.
>>
>> PERIOD.
>
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-11 23:58 -0400 |
| Message-ID | <VlRLM.1202$HpPd.216@fx03.iad> |
| In reply to | #91673 |
Chris M. Thomasson wrote:
> On 9/10/2023 3:50 PM, Pavel wrote:
>> Richard Damon wrote:
>>> On 9/10/23 1:57 AM, Bonita Montero wrote:
>>>> Am 09.09.2023 um 22:37 schrieb Richard Damon:
>>>>
>>>>> The Standard defines the final results that must happen
>>>>> (or possibilities that can happen in some cases).
>>>>
>>>> The standards also should consider side effects as in this example
>>>> when a static initialization would fail because of a synchronization
>>>> error.
>>>>
>>> You don't seem to understand that sincd it CAN be done in a way that
>>> always works, any method that doesn't always work is just WRONG and
>>> non-conforming.
>>>
>>> I guess you think that 1 + 1 must be allowed to be 1 in case of
>>> "synchronization errors".
>>>
>>> Static Initialization has DEFINED behavior, and that behavior must be
>>> honored, and the implementation do what is need to make that happen.
>>>
>>> Methods have been shown to do it (perhaps less performant than this
>>> is some conditions),
>> Actually, I think there should be always a better-performing method to
>> implement C++ static initialization than using windows or pthread
>> mutex -- e.g. using a specialized control like those used for
>> call_once implementation -- at least on UNIX or Windows.
>>
>> This is because IMHO mutex API is a textbook case of feature bloat on
>> both platforms.
>>
>> E.g. in standard UNIX (former POSIX), you can have recursive / robust
>> / shared / errorcheck mutex (not all mutually exclusive) and who knows
>> what else. pthread_mutex_lock shall be able to deal with either
>> combination and the feature-check code makes (at least the current)
>> implementation quite messy, with multiple dispatches on the same
>> condition.
>>
>> On Windows, the number of options is less; but, to compensate for that
>> :-), a mutex is always recursive plus wait functions have to know how
>> to deal with inter-process mutexes because any handle passed to them
>> can turn out to be of an inter-process mutex (or even not a mutex at
>> all). Therefore, I do not think their use for static initialization
>> (that does not require either recursive or inter-process lock) even
>> could be optimal.
>
> I might be missing your point here. Humm... Even though POSIX has all of
> these different types of mutexs, we can use them by organization.
The point is that, even assuming that all types of mutices are very well
organized in the implementation, some dispatch of control still has to
occur when one calls "pthread_mutex_lock" because it is a single entry
point for locking a mutex with any combination of features. Given that
locking of a non-contended mutex is supposed to be (and in fact is, on
current Linux) very cheap (but not necessarily same-cheap if the mutex
is recursive :-) ), the relative cost of this dispatch is not guaranteed
to be negligible (even if that dispatch is implemented via a single
extra level of indirection).
Further, I am unsure if these features actually *can* be very well
organized because not all features of mutices are mutually exclusive (no
pun intended) so a single extra level of indirection might not be enugh.
As an example, mutexattr type can be one of
PTHREAD_MUTEX_NORMAL PTHREAD_MUTEX_ERRORCHECK PTHREAD_MUTEX_RECURSIVE
PTHREAD_MUTEX_DEFAULT
but each of these can be additionally either robust or non-robust (and,
pthread_mutex_lock is supposed to behave differently for some
combinations of type and robustness). Unless of course we dispatch to a
cartesian product of options (which is not impossible, but see below).
And, lastly, the above are all hypotheticals and the actual code (see
e.g. https://codebrowser.dev/glibc/glibc/nptl/pthread_mutex_lock.c.html
) is slightly messier than the best organized implementation possible.
From practical perspective, I would expect that someone implementing a
thread-safe static initialization in a C++ compiler has their mouth full
with the tasks other than improving the existing pthread_mutex (or
pthread_once) implementation as a distraction; at most (I would
speculate), they would take a quick (~5 min) look into the API and the
available code of the existing established synchronization primitives
and decide which one is likely to better fit their spec and be faster
as-is to use to implement that pesky initialization spec. In this
scenario, I would guess that pthread_once_t would win the beauty contest
and get selected.
And, sure enough, (likely due to no feature bloat) the *existing*
pthread_once implementation code is much cleaner (see
https://codebrowser.dev/glibc/glibc/nptl/pthread_once.c.html) and at
first glance should be measurably faster.
I guess, instead of guessing, (no pun untended again), we could just
disassemble some static initialization and see how it's done in, say,
gcc. Maybe later...
> So,
> wrt windows, an intra-process mutex can be a CRITICAL_SECTION. Or an
> inter-process as a mutex HANDLE.
>
> https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexexa
>
>
> Wrt the inter-process route we may need to deal with WAIT_ABANDONED, or
> EOWNERDEAD wrt POSIX. So we create different types:
>
>
> struct intra_process_mutex
> {
> CRITICAL_SECTION m_os_lock;
> };
>
>
> struct inter_process_mutex
> {
> HANDLE m_os_lock;
> };
>
> struct inter_process_mutex_robust
> {
> HANDLE m_os_lock;
> };
>
>
>
> These simple types can be rather easy to reason about. Wrt POSIX, the
> different types would be:
>
>
> struct intra_process_mutex
> {
> pthread_mutex_t m_os_lock;
> };
>
>
> struct inter_process_mutex
> {
> pthread_mutex_t m_os_lock;
> };
>
> struct inter_process_mutex_robust
> {
> pthread_mutex_t m_os_lock;
> };
>
>
> The point is trying to organize things a bit here.
>
> Sound somewhat decent?
>
>
>>
>>> so it is possible, so you can't say the Standard is asking for
>>> impossible behavior, thus any "optimizations" that don't meet that
>>> defined behavior are just WRONG.
>>>
>>> Saying something wrong must be made right is just WRONG, so you are
>>> WRONG in your claim.
>>>
>>> PERIOD.
>>
>
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-17 14:02 -0700 |
| Message-ID | <ue7phh$hmk6$1@dont-email.me> |
| In reply to | #91695 |
On 9/11/2023 8:58 PM, Pavel wrote:
> Chris M. Thomasson wrote:
>> On 9/10/2023 3:50 PM, Pavel wrote:
>>> Richard Damon wrote:
>>>> On 9/10/23 1:57 AM, Bonita Montero wrote:
>>>>> Am 09.09.2023 um 22:37 schrieb Richard Damon:
>>>>>
>>>>>> The Standard defines the final results that must happen
>>>>>> (or possibilities that can happen in some cases).
>>>>>
>>>>> The standards also should consider side effects as in this example
>>>>> when a static initialization would fail because of a synchronization
>>>>> error.
>>>>>
>>>> You don't seem to understand that sincd it CAN be done in a way that
>>>> always works, any method that doesn't always work is just WRONG and
>>>> non-conforming.
>>>>
>>>> I guess you think that 1 + 1 must be allowed to be 1 in case of
>>>> "synchronization errors".
>>>>
>>>> Static Initialization has DEFINED behavior, and that behavior must
>>>> be honored, and the implementation do what is need to make that happen.
>>>>
>>>> Methods have been shown to do it (perhaps less performant than this
>>>> is some conditions),
>>> Actually, I think there should be always a better-performing method
>>> to implement C++ static initialization than using windows or pthread
>>> mutex -- e.g. using a specialized control like those used for
>>> call_once implementation -- at least on UNIX or Windows.
>>>
>>> This is because IMHO mutex API is a textbook case of feature bloat on
>>> both platforms.
>>>
>>> E.g. in standard UNIX (former POSIX), you can have recursive / robust
>>> / shared / errorcheck mutex (not all mutually exclusive) and who
>>> knows what else. pthread_mutex_lock shall be able to deal with either
>>> combination and the feature-check code makes (at least the current)
>>> implementation quite messy, with multiple dispatches on the same
>>> condition.
>>>
>>> On Windows, the number of options is less; but, to compensate for
>>> that :-), a mutex is always recursive plus wait functions have to
>>> know how to deal with inter-process mutexes because any handle passed
>>> to them can turn out to be of an inter-process mutex (or even not a
>>> mutex at all). Therefore, I do not think their use for static
>>> initialization (that does not require either recursive or
>>> inter-process lock) even could be optimal.
>>
>> I might be missing your point here. Humm... Even though POSIX has all
>> of these different types of mutexs, we can use them by organization.
> The point is that, even assuming that all types of mutices are very well
> organized in the implementation, some dispatch of control still has to
> occur when one calls "pthread_mutex_lock" because it is a single entry
> point for locking a mutex with any combination of features. Given that
> locking of a non-contended mutex is supposed to be (and in fact is, on
> current Linux) very cheap (but not necessarily same-cheap if the mutex
> is recursive :-) ), the relative cost of this dispatch is not guaranteed
> to be negligible (even if that dispatch is implemented via a single
> extra level of indirection).
>
> Further, I am unsure if these features actually *can* be very well
> organized because not all features of mutices are mutually exclusive (no
> pun intended) so a single extra level of indirection might not be enugh.
> As an example, mutexattr type can be one of
>
> PTHREAD_MUTEX_NORMAL PTHREAD_MUTEX_ERRORCHECK PTHREAD_MUTEX_RECURSIVE
> PTHREAD_MUTEX_DEFAULT
Yeah. It's up to us programmers to make sure everything is right on our
end. What about:
intra_process_mutex_recursive m_mutex_recurive;
I find that a more descriptive name can help wrt reading code created by
somebody else. Humm... Actaly, I do not like to use recursive mutexes
very much (if at all) because I have had to debug some other peoples
"nightmare" code that recursed, and caused a deadlock around four locks
deep.... It technically was not the fault of the recursion ability, but
it was an error on the programmers side. The name of the lock was
something like (object.m_lock), it was vague and I did not even know it
recursed until I took a deeper look at the damn "nightmare" code. So,
iirc, I said out loud, name it something else... How about:
object.m_lock_recusive__never__use__
and got a laugh from the room. :^)
>
> but each of these can be additionally either robust or non-robust (and,
> pthread_mutex_lock is supposed to behave differently for some
> combinations of type and robustness). Unless of course we dispatch to a
> cartesian product of options (which is not impossible, but see below).
>
> And, lastly, the above are all hypotheticals and the actual code (see
> e.g. https://codebrowser.dev/glibc/glibc/nptl/pthread_mutex_lock.c.html
> ) is slightly messier than the best organized implementation possible.
> From practical perspective, I would expect that someone implementing a
> thread-safe static initialization in a C++ compiler has their mouth full
> with the tasks other than improving the existing pthread_mutex (or
> pthread_once) implementation as a distraction; at most (I would
> speculate), they would take a quick (~5 min) look into the API and the
> available code of the existing established synchronization primitives
> and decide which one is likely to better fit their spec and be faster
> as-is to use to implement that pesky initialization spec. In this
> scenario, I would guess that pthread_once_t would win the beauty contest
> and get selected.
>
> And, sure enough, (likely due to no feature bloat) the *existing*
> pthread_once implementation code is much cleaner (see
> https://codebrowser.dev/glibc/glibc/nptl/pthread_once.c.html) and at
> first glance should be measurably faster.
>
> I guess, instead of guessing, (no pun untended again), we could just
> disassemble some static initialization and see how it's done in, say,
> gcc. Maybe later...
>
>> So, wrt windows, an intra-process mutex can be a CRITICAL_SECTION. Or
>> an inter-process as a mutex HANDLE.
>>
>> https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexexa
>>
>> Wrt the inter-process route we may need to deal with WAIT_ABANDONED,
>> or EOWNERDEAD wrt POSIX. So we create different types:
>>
>>
>> struct intra_process_mutex
>> {
>> CRITICAL_SECTION m_os_lock;
>> };
>>
>>
>> struct inter_process_mutex
>> {
>> HANDLE m_os_lock;
>> };
>>
>> struct inter_process_mutex_robust
>> {
>> HANDLE m_os_lock;
>> };
>>
>>
>>
>> These simple types can be rather easy to reason about. Wrt POSIX, the
>> different types would be:
>>
>>
>> struct intra_process_mutex
>> {
>> pthread_mutex_t m_os_lock;
>> };
>>
>>
>> struct inter_process_mutex
>> {
>> pthread_mutex_t m_os_lock;
>> };
>>
>> struct inter_process_mutex_robust
>> {
>> pthread_mutex_t m_os_lock;
>> };
>>
>>
>> The point is trying to organize things a bit here.
>>
>> Sound somewhat decent?
>>
>>
>>>
>>>> so it is possible, so you can't say the Standard is asking for
>>>> impossible behavior, thus any "optimizations" that don't meet that
>>>> defined behavior are just WRONG.
>>>>
>>>> Saying something wrong must be made right is just WRONG, so you are
>>>> WRONG in your claim.
>>>>
>>>> PERIOD.
>>>
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-18 20:11 -0400 |
| Message-ID | <8H5OM.30728$Yxl8.29787@fx14.iad> |
| In reply to | #91775 |
Chris M. Thomasson wrote:
> On 9/11/2023 8:58 PM, Pavel wrote:
>> Chris M. Thomasson wrote:
>>> On 9/10/2023 3:50 PM, Pavel wrote:
>>>> Richard Damon wrote:
>>>>> On 9/10/23 1:57 AM, Bonita Montero wrote:
>>>>>> Am 09.09.2023 um 22:37 schrieb Richard Damon:
>>>>>>
>>>>>>> The Standard defines the final results that must happen
>>>>>>> (or possibilities that can happen in some cases).
>>>>>>
>>>>>> The standards also should consider side effects as in this example
>>>>>> when a static initialization would fail because of a synchronization
>>>>>> error.
>>>>>>
>>>>> You don't seem to understand that sincd it CAN be done in a way
>>>>> that always works, any method that doesn't always work is just
>>>>> WRONG and non-conforming.
>>>>>
>>>>> I guess you think that 1 + 1 must be allowed to be 1 in case of
>>>>> "synchronization errors".
>>>>>
>>>>> Static Initialization has DEFINED behavior, and that behavior must
>>>>> be honored, and the implementation do what is need to make that
>>>>> happen.
>>>>>
>>>>> Methods have been shown to do it (perhaps less performant than this
>>>>> is some conditions),
>>>> Actually, I think there should be always a better-performing method
>>>> to implement C++ static initialization than using windows or pthread
>>>> mutex -- e.g. using a specialized control like those used for
>>>> call_once implementation -- at least on UNIX or Windows.
>>>>
>>>> This is because IMHO mutex API is a textbook case of feature bloat
>>>> on both platforms.
>>>>
>>>> E.g. in standard UNIX (former POSIX), you can have recursive /
>>>> robust / shared / errorcheck mutex (not all mutually exclusive) and
>>>> who knows what else. pthread_mutex_lock shall be able to deal with
>>>> either combination and the feature-check code makes (at least the
>>>> current) implementation quite messy, with multiple dispatches on the
>>>> same condition.
>>>>
>>>> On Windows, the number of options is less; but, to compensate for
>>>> that :-), a mutex is always recursive plus wait functions have to
>>>> know how to deal with inter-process mutexes because any handle
>>>> passed to them can turn out to be of an inter-process mutex (or even
>>>> not a mutex at all). Therefore, I do not think their use for static
>>>> initialization (that does not require either recursive or
>>>> inter-process lock) even could be optimal.
>>>
>>> I might be missing your point here. Humm... Even though POSIX has all
>>> of these different types of mutexs, we can use them by organization.
>> The point is that, even assuming that all types of mutices are very
>> well organized in the implementation, some dispatch of control still
>> has to occur when one calls "pthread_mutex_lock" because it is a
>> single entry point for locking a mutex with any combination of
>> features. Given that locking of a non-contended mutex is supposed to
>> be (and in fact is, on current Linux) very cheap (but not necessarily
>> same-cheap if the mutex is recursive :-) ), the relative cost of this
>> dispatch is not guaranteed to be negligible (even if that dispatch is
>> implemented via a single extra level of indirection).
>>
>> Further, I am unsure if these features actually *can* be very well
>> organized because not all features of mutices are mutually exclusive
>> (no pun intended) so a single extra level of indirection might not be
>> enugh. As an example, mutexattr type can be one of
>>
>> PTHREAD_MUTEX_NORMAL PTHREAD_MUTEX_ERRORCHECK
>> PTHREAD_MUTEX_RECURSIVE PTHREAD_MUTEX_DEFAULT
>
> Yeah. It's up to us programmers to make sure everything is right on our
> end. What about:
>
> intra_process_mutex_recursive m_mutex_recurive;
Agree, good names are important for readability.
The issue with POSIX mutex is that there is only one C type for all
mutex types, pthread_mutex_t so at least one dispatch is necessary (and,
at least in the current Linux implementation, many dispatches are done).
>
> I find that a more descriptive name can help wrt reading code created by
> somebody else. Humm... Actaly, I do not like to use recursive mutexes
> very much (if at all) because I have had to debug some other peoples
> "nightmare" code that recursed, and caused a deadlock around four locks
> deep.... It technically was not the fault of the recursion ability, but
> it was an error on the programmers side. The name of the lock was
> something like (object.m_lock), it was vague and I did not even know it
> recursed until I took a deeper look at the damn "nightmare" code. So,
> iirc, I said out loud, name it something else... How about:
>
> object.m_lock_recusive__never__use__
>
> and got a laugh from the room. :^)
>
>
>
>
>
>>
>> but each of these can be additionally either robust or non-robust
>> (and, pthread_mutex_lock is supposed to behave differently for some
>> combinations of type and robustness). Unless of course we dispatch to
>> a cartesian product of options (which is not impossible, but see below).
>>
>> And, lastly, the above are all hypotheticals and the actual code (see
>> e.g.
>> https://codebrowser.dev/glibc/glibc/nptl/pthread_mutex_lock.c.html )
>> is slightly messier than the best organized implementation possible.
>> From practical perspective, I would expect that someone implementing
>> a thread-safe static initialization in a C++ compiler has their mouth
>> full with the tasks other than improving the existing pthread_mutex
>> (or pthread_once) implementation as a distraction; at most (I would
>> speculate), they would take a quick (~5 min) look into the API and the
>> available code of the existing established synchronization primitives
>> and decide which one is likely to better fit their spec and be faster
>> as-is to use to implement that pesky initialization spec. In this
>> scenario, I would guess that pthread_once_t would win the beauty
>> contest and get selected.
>>
>> And, sure enough, (likely due to no feature bloat) the *existing*
>> pthread_once implementation code is much cleaner (see
>> https://codebrowser.dev/glibc/glibc/nptl/pthread_once.c.html) and at
>> first glance should be measurably faster.
>>
>> I guess, instead of guessing, (no pun untended again), we could just
>> disassemble some static initialization and see how it's done in, say,
>> gcc. Maybe later...
>>
>>> So, wrt windows, an intra-process mutex can be a CRITICAL_SECTION. Or
>>> an inter-process as a mutex HANDLE.
>>>
>>> https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexexa
>>>
>>>
>>> Wrt the inter-process route we may need to deal with WAIT_ABANDONED,
>>> or EOWNERDEAD wrt POSIX. So we create different types:
>>>
>>>
>>> struct intra_process_mutex
>>> {
>>> CRITICAL_SECTION m_os_lock;
>>> };
>>>
>>>
>>> struct inter_process_mutex
>>> {
>>> HANDLE m_os_lock;
>>> };
>>>
>>> struct inter_process_mutex_robust
>>> {
>>> HANDLE m_os_lock;
>>> };
>>>
>>>
>>>
>>> These simple types can be rather easy to reason about. Wrt POSIX, the
>>> different types would be:
>>>
>>>
>>> struct intra_process_mutex
>>> {
>>> pthread_mutex_t m_os_lock;
>>> };
>>>
>>>
>>> struct inter_process_mutex
>>> {
>>> pthread_mutex_t m_os_lock;
>>> };
>>>
>>> struct inter_process_mutex_robust
>>> {
>>> pthread_mutex_t m_os_lock;
>>> };
>>>
>>>
>>> The point is trying to organize things a bit here.
>>>
>>> Sound somewhat decent?
>>>
>>>
>>>>
>>>>> so it is possible, so you can't say the Standard is asking for
>>>>> impossible behavior, thus any "optimizations" that don't meet that
>>>>> defined behavior are just WRONG.
>>>>>
>>>>> Saying something wrong must be made right is just WRONG, so you are
>>>>> WRONG in your claim.
>>>>>
>>>>> PERIOD.
>>>>
>>>
>>
>
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-10 11:12 -0700 |
| Message-ID | <udl0v2$lp5v$5@dont-email.me> |
| In reply to | #91642 |
On 9/10/2023 1:57 AM, Bonita Montero wrote: > Am 09.09.2023 um 22:37 schrieb Richard Damon: > >> The Standard defines the final results that must happen >> (or possibilities that can happen in some cases). > > The standards also should consider side effects as in this example > when a static initialization would fail because of a synchronization > error. > What error?
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-10 18:05 -0400 |
| Message-ID | <V4rLM.868795$U3w1.60865@fx09.iad> |
| In reply to | #91629 |
Bonita Montero wrote: > Am 09.09.2023 um 19:42 schrieb Pavel: > >> If Microsoft implemented standard wrongly, it's Microsoft's failure, >> not the standard's. > > The standard doesn't say anything to the issue I've shown. > You did not show any issue, you just guessed what the implementation could be and assumed there could be an issue. After looking at InitOnceExecuteOnce API pointed out by Chris I think it is very likely that your guess on implementation was wrong.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-09 11:49 -0700 |
| Message-ID | <udieo4$63u7$4@dont-email.me> |
| In reply to | #91621 |
On 9/9/2023 10:26 AM, Bonita Montero wrote:
> Am 09.09.2023 um 16:54 schrieb Paavo Helde:
>
>> From there I can see that it calls atomic_load_acquire(). Only if
>> this fails, will it call __pthread_once_slow() in the slow branch,
>> which uses futexes. Some other googling reveals that: "a futex ("Fast
>> Userspace Mutex") isn't a mutex at all"
>
> Doesn't matter since the standard should honor static initialization
> that fails because of synchronization woes. And as I've shown with
> my code MSVC, libstdc++ and libc++ have a mutex per static initiali-
> zation, so pthread_once doesn't apply here.
Huh? pthread_once totally applies here. Windows has futex like abilities.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-09 21:17 +0200 |
| Message-ID | <udigbv$6ddc$2@dont-email.me> |
| In reply to | #91628 |
Am 09.09.2023 um 20:49 schrieb Chris M. Thomasson: > Huh? pthread_once totally applies here. Windows has futex like abilities. It doesn't matter what Posix or Win32 says. The standard should honour that static initialization might fail because of creating a synchronization primitive or synchronizing on them. The standard shoudln't require that this never fails.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-09 12:20 -0700 |
| Message-ID | <udigh5$6amo$4@dont-email.me> |
| In reply to | #91630 |
On 9/9/2023 12:17 PM, Bonita Montero wrote: > Am 09.09.2023 um 20:49 schrieb Chris M. Thomasson: > >> Huh? pthread_once totally applies here. Windows has futex like abilities. > > It doesn't matter what Posix or Win32 says. Are you sure about that? > The standard should > honour that static initialization might fail because of creating > a synchronization primitive or synchronizing on them. The standard > shoudln't require that this never fails. > Might fail? For what reasons?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-09 21:55 +0200 |
| Message-ID | <udiiim$6ngs$1@dont-email.me> |
| In reply to | #91631 |
Am 09.09.2023 um 21:20 schrieb Chris M. Thomasson: >> It doesn't matter what Posix or Win32 says. > Are you sure about that? The standard is operating system agnostic. > Might fail? For what reasons? F.e. because there's no more non-pageable memory for a semaphore.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-09 12:59 -0700 |
| Message-ID | <udiiqu$6ih8$2@dont-email.me> |
| In reply to | #91636 |
On 9/9/2023 12:55 PM, Bonita Montero wrote: > Am 09.09.2023 um 21:20 schrieb Chris M. Thomasson: > >>> It doesn't matter what Posix or Win32 says. > >> Are you sure about that? > > The standard is operating system agnostic. > >> Might fail? For what reasons? > > F.e. because there's no more non-pageable memory for a semaphore. > An address based hash into a table based approach works by creating everything up front. If this fails, then the user program logic is not even executed at all.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-09 13:00 -0700 |
| Message-ID | <udiisq$6ih8$3@dont-email.me> |
| In reply to | #91637 |
On 9/9/2023 12:59 PM, Chris M. Thomasson wrote: > On 9/9/2023 12:55 PM, Bonita Montero wrote: >> Am 09.09.2023 um 21:20 schrieb Chris M. Thomasson: >> >>>> It doesn't matter what Posix or Win32 says. >> >>> Are you sure about that? >> >> The standard is operating system agnostic. >> >>> Might fail? For what reasons? >> >> F.e. because there's no more non-pageable memory for a semaphore. >> > > An address based hash into a table based approach works by creating > everything up front. If this fails, then the user program logic is not > even executed at all. Just one way.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-10 10:58 +0200 |
| Message-ID | <udk0g7$h1e9$2@dont-email.me> |
| In reply to | #91637 |
Am 09.09.2023 um 21:59 schrieb Chris M. Thomasson: > On 9/9/2023 12:55 PM, Bonita Montero wrote: >> F.e. because there's no more non-pageable memory for a semaphore. > An address based hash into a table based approach works by creating > everything up front. If this fails, then the user program logic is > not even executed at all. Do you want to follow in Amine's footsteps ?
[toc] | [prev] | [next] | [standalone]
Page 3 of 34 — ← Prev page 1 2 [3] 4 5 … 34 Next page →
Back to top | Article view | comp.lang.c++
csiph-web