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 1 of 34 [1] 2 3 … 34 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-06 20:15 +0200 |
| Subject | Thread-safe initialization of static objects |
| Message-ID | <udafjf$2joeq$1@dont-email.me> |
With C++11 static local or global data is initialized thread-safe.
This is usually done with double checked locking (DCL). DCL needs
a flag along with the static data which shows if the data already
is initialized and a mutex which guards the initalization.
I assumed that an implementation simply would use a central mutex
for all static data objects since it includes a kernel semaphore,
which is a costly resource.
To find out if this is true I wrote the below application:
#include <iostream>
#include <thread>
#include <vector>
using namespace std;
template<unsigned Thread>
struct SleepAtInitialize
{
SleepAtInitialize()
{
this_thread::sleep_for( 1s );
}
};
int main()
{
auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>, auto
fn )
{
((fn.template operator ()<Indices>()), ...);
};
constexpr unsigned N_THREADS = 10;
vector<jthread> threads;
threads.reserve( N_THREADS );
unroll( make_index_sequence<N_THREADS>(),
[&]<unsigned Thread>()
{
threads.emplace_back( [&]<unsigned IObj>(integral_constant<unsigned,
IObj> )
{
static SleepAtInitialize<IObj> guard;
}, integral_constant<unsigned, Thread>() );
} );
}
SleepAtInitialize<IObj> is instantiated only once per thread with this
code. So the threads don't share a central object. If there would be
a central mutex used the above code would run for about 10s. But the
code does run about one second, i.e. there are indivual mutexes per
each instantiation of SleepAtInitiaize<>. I.e. the creation of the
mutex is also done with the static initialization. The mutex constructor
is noexcept, so mutexes always must be created on their first use. This
is done while the DCL-locked creation of the static object. So at last
static initialization should be declared to throw a system_errror. But
I can't find anything about that in the standard.
[toc] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-06 18:44 -0400 |
| Message-ID | <1h7KM.66324$Wk53.59929@fx01.iad> |
| In reply to | #91550 |
Bonita Montero wrote:
> With C++11 static local or global data is initialized thread-safe.
> This is usually done with double checked locking (DCL). DCL needs
> a flag along with the static data which shows if the data already
> is initialized and a mutex which guards the initalization.
Not needed. A test-and-set instruction on a flag -- that is itself
constant-initialized -- is sufficient.
> I assumed that an implementation simply would use a central mutex
> for all static data objects since it includes a kernel semaphore,
> which is a costly resource.
> To find out if this is true I wrote the below application:
>
> #include <iostream>
> #include <thread>
> #include <vector>
>
> using namespace std;
>
> template<unsigned Thread>
> struct SleepAtInitialize
> {
> SleepAtInitialize()
> {
> this_thread::sleep_for( 1s );
> }
> };
>
> int main()
> {
> auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>,
> auto fn )
> {
> ((fn.template operator ()<Indices>()), ...);
> };
> constexpr unsigned N_THREADS = 10;
> vector<jthread> threads;
> threads.reserve( N_THREADS );
> unroll( make_index_sequence<N_THREADS>(),
> [&]<unsigned Thread>()
> {
> threads.emplace_back( [&]<unsigned
> IObj>(integral_constant<unsigned, IObj> )
> {
> static SleepAtInitialize<IObj> guard;
> }, integral_constant<unsigned, Thread>() );
> } );
>
> }
>
> SleepAtInitialize<IObj> is instantiated only once per thread with this
> code. So the threads don't share a central object. If there would be
> a central mutex used the above code would run for about 10s. But the
> code does run about one second, i.e. there are indivual mutexes per
> each instantiation of SleepAtInitiaize<>. I.e. the creation of the
> mutex is also done with the static initialization. The mutex constructor
> is noexcept, so mutexes always must be created on their first use. This
> is done while the DCL-locked creation of the static object. So at last
> static initialization should be declared to throw a system_errror. But
> I can't find anything about that in the standard.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-07 04:54 +0200 |
| Message-ID | <udbe19$2rk0p$2@dont-email.me> |
| In reply to | #91555 |
Am 07.09.2023 um 00:44 schrieb Pavel: > Bonita Montero wrote: >> With C++11 static local or global data is initialized thread-safe. >> This is usually done with double checked locking (DCL). DCL needs >> a flag along with the static data which shows if the data already >> is initialized and a mutex which guards the initalization. > Not needed. A test-and-set instruction on a flag -- that is itself > constant-initialized -- is sufficient. Using only one flag would require spin-locking. However, spin-locking is not possible in userspace because a thread holding a spinlock could keep other threads spinning for a long time. Therefore, there is no getting around a solution with a mutex. And creation and mutex synchro- nization may fail.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-07 00:18 -0400 |
| Message-ID | <2acKM.719164$U3w1.269152@fx09.iad> |
| In reply to | #91559 |
Bonita Montero wrote: > Am 07.09.2023 um 00:44 schrieb Pavel: >> Bonita Montero wrote: >>> With C++11 static local or global data is initialized thread-safe. >>> This is usually done with double checked locking (DCL). DCL needs >>> a flag along with the static data which shows if the data already >>> is initialized and a mutex which guards the initalization. > >> Not needed. A test-and-set instruction on a flag -- that is itself >> constant-initialized -- is sufficient. > > Using only one flag would require spin-locking. However, spin-locking > is not possible in userspace not true, a loop with yield in the body is very possible. > because a thread holding a spinlock could > keep other threads spinning for a long time. Therefore, there is no > getting around a solution with a mutex. does not have to be a mutex, can be call_once, a semaphore, anything, actually. > And creation and mutex synchro- > nization may fail. If initialization synchronization fails, the initialization can catch and terminate. No need to throw a system error. No need to use C++ synchronization primitives in the initialization code either; nothing prevents the implementation from being implemented in a platform-specific manner.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-07 06:27 +0200 |
| Message-ID | <udbjfo$2s7cn$1@dont-email.me> |
| In reply to | #91561 |
Am 07.09.2023 um 06:18 schrieb Pavel: > not true, a loop with yield in the body is very possible. No one would accept that because that would make the waiters to wait much more longer than necessary. > does not have to be a mutex, can be call_once, a semaphore, anything, > actually. Every applicable facility for that would rely on kernel-synchronization. You'd need to create a binary semaphore for that and you need so syn- chronize on that; both may fail. > If initialization synchronization fails, the initialization can catch > and terminate. ... Nothing like that is specified.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-07 10:44 -0400 |
| Message-ID | <RllKM.1028889$SuUf.692033@fx14.iad> |
| In reply to | #91562 |
Bonita Montero wrote: > Am 07.09.2023 um 06:18 schrieb Pavel: > >> not true, a loop with yield in the body is very possible. > > No one would accept that because that would make the waiters to wait > much more longer than necessary. How so? Waiters will wait for the time of initialization. The initializing thread will be yielded to and receive virtually as many and as complete time slices as it would under any other scheduling discipline so it will complete its job in same or virtually same time (actually, the higher system contention level is the more efficient user-space waiting with yield becomes). Hence the time waiters will wait is exactly or virtually same as when using mutex. Also it should be taken into account that all above (and below) is only relevant to the rare case when the initialization is contended; in other words, "no one would accept" would be an exaggeration of the year even if your speculation on "wait much longer" were true -- which it isn't. > >> does not have to be a mutex, can be call_once, a semaphore, anything, >> actually. > > Every applicable facility for that would rely on kernel-synchronization. > You'd need to create a binary semaphore for that and you need so syn- > chronize on that; both may fail. try_lock in a loop with a sleep or yield wouldn't fail. But as said above, it's not needed. Regardless, your argument assumes too much C++-morphism in the implementation whereas the implementation can use any platform-specific approach available to it. E.g. pthread_once on Linux does not fail if given valid arguments (which C++ implementation can provide). Other platforms may have tools of their own to do the job. > >> If initialization synchronization fails, the initialization can catch >> and terminate. ... > > Nothing like that is specified. Correct, the above was wrong. But initialization can catch and try again. This does not have to be specified as it is not observable from outside.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-07 18:39 +0200 |
| Message-ID | <udcubm$325k4$1@dont-email.me> |
| In reply to | #91570 |
Am 07.09.2023 um 16:44 schrieb Pavel:
> How so? Waiters will wait for the time of initialization.
> The initializing thread will be yielded ...
Initializing is usually much faster than a whole timeslice,
so yielding would be incacceptabel. That's just a stupid idea.
> try_lock in a loop with a sleep or yield wouldn't fail. ...
Do you really think someone would accept spinning with that ?
This means that an initializing thread which is scheduled away
while holding the mutex might keep other threads spinning for
a long time.
> Regardless, your argument assumes too much C++-morphism in the
> implementation whereas the implementation can use any platform
> -specific approach available to it. E.g. pthread_once on Linux
> does not fail if given valid arguments ...
pthread_once could be implemented with a single central semaphore for
all operations and if the implementers know that the synchronization
itself doesn't fail and the semphore is pre-allocated by the runtime
it's possible to survive that synchronization without error.
But check that code:
#include <iostream>
#include <thread>
#include <vector>
using namespace std;
template<unsigned Thread>
struct SleepAtInitialize
{
SleepAtInitialize()
{
this_thread::sleep_for( 1s );
}
};
int main()
{
auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>, auto
fn )
{
((fn.template operator ()<Indices>()), ...);
};
constexpr unsigned N_THREADS = 10;
vector<jthread> threads;
threads.reserve( N_THREADS );
unroll( make_index_sequence<N_THREADS>(),
[&]<unsigned Thread>()
{
threads.emplace_back(
[&]<unsigned IObj>( integral_constant<unsigned, IObj> )
{
static SleepAtInitialize<IObj> guard;
}, integral_constant<unsigned, Thread>() );
} );
}
This code runs with individual mutexes per object, i.e. the time
taken is about one second (with MSVC, libc++ and libstdc++). So
when individual mutexes are used the initialization may fail.
> Correct, the above was wrong. But initialization can catch and try
> again. ...
That a bumbler solution.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 17:27 +0000 |
| Message-ID | <kKnKM.340818$ens9.154535@fx45.iad> |
| In reply to | #91575 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 07.09.2023 um 16:44 schrieb Pavel: > >> How so? Waiters will wait for the time of initialization. >> The initializing thread will be yielded ... > >Initializing is usually much faster than a whole timeslice, >so yielding would be incacceptabel. That's just a stupid idea. So tell us, on which operating systems will there be more than one thread running when application static objects are initialized (which happens generally before the application 'main' function is called, and thus before the application has a chance to create any threads)?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-07 11:06 -0700 |
| Message-ID | <XioKM.273960$8_8a.80813@fx48.iad> |
| In reply to | #91576 |
On 9/7/23 10:27 AM, Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 07.09.2023 um 16:44 schrieb Pavel: >> >>> How so? Waiters will wait for the time of initialization. >>> The initializing thread will be yielded ... >> >> Initializing is usually much faster than a whole timeslice, >> so yielding would be incacceptabel. That's just a stupid idea. > > So tell us, on which operating systems will there be more than > one thread running when application static objects are > initialized (which happens generally before the application > 'main' function is called, and thus before the application > has a chance to create any threads)? While GLOBAL static objects get initialized before main starts, function local static objects don't get initialized until the first call of the function. These will need some synchronization if the function is called from multiple threads at "the same time". Also, some global object could start up a thread in its constructor.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-07 12:20 -0700 |
| Message-ID | <udd7q8$33i0n$1@dont-email.me> |
| In reply to | #91577 |
On 9/7/2023 11:06 AM, Richard Damon wrote: > On 9/7/23 10:27 AM, Scott Lurndal wrote: >> Bonita Montero <Bonita.Montero@gmail.com> writes: >>> Am 07.09.2023 um 16:44 schrieb Pavel: >>> >>>> How so? Waiters will wait for the time of initialization. >>>> The initializing thread will be yielded ... >>> >>> Initializing is usually much faster than a whole timeslice, >>> so yielding would be incacceptabel. That's just a stupid idea. >> >> So tell us, on which operating systems will there be more than >> one thread running when application static objects are >> initialized (which happens generally before the application >> 'main' function is called, and thus before the application >> has a chance to create any threads)? > > While GLOBAL static objects get initialized before main starts, function > local static objects don't get initialized until the first call of the > function. These will need some synchronization if the function is called > from multiple threads at "the same time". A simple global hash lock scheme is where we can hash addresses directly into a static locking table. The lock table is created _before_ any program logic is executed. https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ > Also, some global object could start up a thread in its constructor. YIKES! Shit. I have had to debug other peoples code that did this. Many points of errors... One was a rather common peach of a bug. The constructor would create a thread that would in turn call into a virtual function and start using the object before its constructor was completed. A massive race condition, nasty ones!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-07 12:52 -0700 |
| Message-ID | <ARpKM.1180716$TPw2.772076@fx17.iad> |
| In reply to | #91580 |
On 9/7/23 12:20 PM, Chris M. Thomasson wrote: > On 9/7/2023 11:06 AM, Richard Damon wrote: >> On 9/7/23 10:27 AM, Scott Lurndal wrote: >>> Bonita Montero <Bonita.Montero@gmail.com> writes: >>>> Am 07.09.2023 um 16:44 schrieb Pavel: >>>> >>>>> How so? Waiters will wait for the time of initialization. >>>>> The initializing thread will be yielded ... >>>> >>>> Initializing is usually much faster than a whole timeslice, >>>> so yielding would be incacceptabel. That's just a stupid idea. >>> >>> So tell us, on which operating systems will there be more than >>> one thread running when application static objects are >>> initialized (which happens generally before the application >>> 'main' function is called, and thus before the application >>> has a chance to create any threads)? >> >> While GLOBAL static objects get initialized before main starts, >> function local static objects don't get initialized until the first >> call of the function. These will need some synchronization if the >> function is called from multiple threads at "the same time". > > A simple global hash lock scheme is where we can hash addresses directly > into a static locking table. The lock table is created _before_ any > program logic is executed. > > https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ > > >> Also, some global object could start up a thread in its constructor. > > YIKES! Shit. I have had to debug other peoples code that did this. Many > points of errors... One was a rather common peach of a bug. The > constructor would create a thread that would in turn call into a virtual > function and start using the object before its constructor was > completed. A massive race condition, nasty ones! > Yes, such a thread needs to understand that the system isn't fully configured. And yes, a base class creating a thread needs that thread to understand that the object isn't fully created yet and do something to handle that issue (which likely requires some help from the most derived class).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-07 12:58 -0700 |
| Message-ID | <udda1r$33t5b$1@dont-email.me> |
| In reply to | #91583 |
On 9/7/2023 12:52 PM, Richard Damon wrote: > On 9/7/23 12:20 PM, Chris M. Thomasson wrote: >> On 9/7/2023 11:06 AM, Richard Damon wrote: >>> On 9/7/23 10:27 AM, Scott Lurndal wrote: >>>> Bonita Montero <Bonita.Montero@gmail.com> writes: >>>>> Am 07.09.2023 um 16:44 schrieb Pavel: >>>>> >>>>>> How so? Waiters will wait for the time of initialization. >>>>>> The initializing thread will be yielded ... >>>>> >>>>> Initializing is usually much faster than a whole timeslice, >>>>> so yielding would be incacceptabel. That's just a stupid idea. >>>> >>>> So tell us, on which operating systems will there be more than >>>> one thread running when application static objects are >>>> initialized (which happens generally before the application >>>> 'main' function is called, and thus before the application >>>> has a chance to create any threads)? >>> >>> While GLOBAL static objects get initialized before main starts, >>> function local static objects don't get initialized until the first >>> call of the function. These will need some synchronization if the >>> function is called from multiple threads at "the same time". >> >> A simple global hash lock scheme is where we can hash addresses >> directly into a static locking table. The lock table is created >> _before_ any program logic is executed. >> >> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ >> >> >>> Also, some global object could start up a thread in its constructor. >> >> YIKES! Shit. I have had to debug other peoples code that did this. >> Many points of errors... One was a rather common peach of a bug. The >> constructor would create a thread that would in turn call into a >> virtual function and start using the object before its constructor was >> completed. A massive race condition, nasty ones! >> > > Yes, such a thread needs to understand that the system isn't fully > configured. And yes, a base class creating a thread needs that thread to > understand that the object isn't fully created yet and do something to > handle that issue (which likely requires some help from the most derived > class). I actually got to a point where I said no creating threads in constructors! I have seen to many problems. Create the object _first_, then expose it to a thread, or create a thread that works with the _fully_ constructed object. The types of race conditions I have had to deal with wrt objects creating threads in constructors have tended to be rather nasty in nature...
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-07 13:31 -0700 |
| Message-ID | <NqqKM.1138349$AsA.720273@fx18.iad> |
| In reply to | #91584 |
On 9/7/23 12:58 PM, Chris M. Thomasson wrote: > On 9/7/2023 12:52 PM, Richard Damon wrote: >> On 9/7/23 12:20 PM, Chris M. Thomasson wrote: >>> On 9/7/2023 11:06 AM, Richard Damon wrote: >>>> On 9/7/23 10:27 AM, Scott Lurndal wrote: >>>>> Bonita Montero <Bonita.Montero@gmail.com> writes: >>>>>> Am 07.09.2023 um 16:44 schrieb Pavel: >>>>>> >>>>>>> How so? Waiters will wait for the time of initialization. >>>>>>> The initializing thread will be yielded ... >>>>>> >>>>>> Initializing is usually much faster than a whole timeslice, >>>>>> so yielding would be incacceptabel. That's just a stupid idea. >>>>> >>>>> So tell us, on which operating systems will there be more than >>>>> one thread running when application static objects are >>>>> initialized (which happens generally before the application >>>>> 'main' function is called, and thus before the application >>>>> has a chance to create any threads)? >>>> >>>> While GLOBAL static objects get initialized before main starts, >>>> function local static objects don't get initialized until the first >>>> call of the function. These will need some synchronization if the >>>> function is called from multiple threads at "the same time". >>> >>> A simple global hash lock scheme is where we can hash addresses >>> directly into a static locking table. The lock table is created >>> _before_ any program logic is executed. >>> >>> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ >>> >>> >>>> Also, some global object could start up a thread in its constructor. >>> >>> YIKES! Shit. I have had to debug other peoples code that did this. >>> Many points of errors... One was a rather common peach of a bug. The >>> constructor would create a thread that would in turn call into a >>> virtual function and start using the object before its constructor >>> was completed. A massive race condition, nasty ones! >>> >> >> Yes, such a thread needs to understand that the system isn't fully >> configured. And yes, a base class creating a thread needs that thread >> to understand that the object isn't fully created yet and do something >> to handle that issue (which likely requires some help from the most >> derived class). > > I actually got to a point where I said no creating threads in > constructors! I have seen to many problems. Create the object _first_, > then expose it to a thread, or create a thread that works with the > _fully_ constructed object. The types of race conditions I have had to > deal with wrt objects creating threads in constructors have tended to be > rather nasty in nature... I have ONE class that does this, but it is for a somewhat specific embedded environment with deterministic scheduling and just a single core, so the thread is created with a lower priority then the creator so it can't start running until the creator blocks, which it isn't allowed to do until the constructor finishes. It also is normally used early in the program before the "OS" is turned on, so the created thread can't actually run until the OS is turned on. But, for the more general case where you can't control that, (under more "normal" conditions on the typical "powerful" computer), yes, that would be a risky thing to be doing.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-08 13:20 -0700 |
| Message-ID | <udfvll$3m1ik$1@dont-email.me> |
| In reply to | #91586 |
On 9/7/2023 1:31 PM, Richard Damon wrote:
> On 9/7/23 12:58 PM, Chris M. Thomasson wrote:
>> On 9/7/2023 12:52 PM, Richard Damon wrote:
>>> On 9/7/23 12:20 PM, Chris M. Thomasson wrote:
>>>> On 9/7/2023 11:06 AM, Richard Damon wrote:
>>>>> On 9/7/23 10:27 AM, Scott Lurndal wrote:
>>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>>> Am 07.09.2023 um 16:44 schrieb Pavel:
>>>>>>>
>>>>>>>> How so? Waiters will wait for the time of initialization.
>>>>>>>> The initializing thread will be yielded ...
>>>>>>>
>>>>>>> Initializing is usually much faster than a whole timeslice,
>>>>>>> so yielding would be incacceptabel. That's just a stupid idea.
>>>>>>
>>>>>> So tell us, on which operating systems will there be more than
>>>>>> one thread running when application static objects are
>>>>>> initialized (which happens generally before the application
>>>>>> 'main' function is called, and thus before the application
>>>>>> has a chance to create any threads)?
>>>>>
>>>>> While GLOBAL static objects get initialized before main starts,
>>>>> function local static objects don't get initialized until the first
>>>>> call of the function. These will need some synchronization if the
>>>>> function is called from multiple threads at "the same time".
>>>>
>>>> A simple global hash lock scheme is where we can hash addresses
>>>> directly into a static locking table. The lock table is created
>>>> _before_ any program logic is executed.
>>>>
>>>> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ
>>>>
>>>>
>>>>> Also, some global object could start up a thread in its constructor.
>>>>
>>>> YIKES! Shit. I have had to debug other peoples code that did this.
>>>> Many points of errors... One was a rather common peach of a bug. The
>>>> constructor would create a thread that would in turn call into a
>>>> virtual function and start using the object before its constructor
>>>> was completed. A massive race condition, nasty ones!
>>>>
>>>
>>> Yes, such a thread needs to understand that the system isn't fully
>>> configured. And yes, a base class creating a thread needs that thread
>>> to understand that the object isn't fully created yet and do
>>> something to handle that issue (which likely requires some help from
>>> the most derived class).
>>
>> I actually got to a point where I said no creating threads in
>> constructors! I have seen to many problems. Create the object _first_,
>> then expose it to a thread, or create a thread that works with the
>> _fully_ constructed object. The types of race conditions I have had to
>> deal with wrt objects creating threads in constructors have tended to
>> be rather nasty in nature...
>
> I have ONE class that does this, but it is for a somewhat specific
> embedded environment with deterministic scheduling and just a single
> core, so the thread is created with a lower priority then the creator so
> it can't start running until the creator blocks, which it isn't allowed
> to do until the constructor finishes. It also is normally used early in
> the program before the "OS" is turned on, so the created thread can't
> actually run until the OS is turned on.
>
> But, for the more general case where you can't control that, (under more
> "normal" conditions on the typical "powerful" computer), yes, that would
> be a risky thing to be doing.
Actually, one way that works pretty good, aka not make me freak out,
lol, wrt creating a thread in a constructor is to create a little proxy
object. Something along the lines of:
template<typename T>
struct thread_proxy
{
T m_object;
std::thread m_thread;
};
We can launch the thread in the constructor of thread_proxy<T>
The thread calls a function in T called thread_entry or whatever. This
ensures that T is 100% _fully_ constructed before the thread is created
and starts working with the damn thing. Imvvvho, this is a lot better
than creating the thread directly in T's constructor.
Actually, I need to get back into threads for some rendering work of mine.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-07 21:13 +0000 |
| Message-ID | <V1rKM.216833$QQFb.22297@fx38.iad> |
| In reply to | #91584 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 9/7/2023 12:52 PM, Richard Damon wrote:
>> On 9/7/23 12:20 PM, Chris M. Thomasson wrote:
>>> On 9/7/2023 11:06 AM, Richard Damon wrote:
>>>> On 9/7/23 10:27 AM, Scott Lurndal wrote:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>> Am 07.09.2023 um 16:44 schrieb Pavel:
>>>>>>
>>>>>>> How so? Waiters will wait for the time of initialization.
>>>>>>> The initializing thread will be yielded ...
>>>>>>
>>>>>> Initializing is usually much faster than a whole timeslice,
>>>>>> so yielding would be incacceptabel. That's just a stupid idea.
>>>>>
>>>>> So tell us, on which operating systems will there be more than
>>>>> one thread running when application static objects are
>>>>> initialized (which happens generally before the application
>>>>> 'main' function is called, and thus before the application
>>>>> has a chance to create any threads)?
>>>>
>>>> While GLOBAL static objects get initialized before main starts,
>>>> function local static objects don't get initialized until the first
>>>> call of the function. These will need some synchronization if the
>>>> function is called from multiple threads at "the same time".
>>>
>>> A simple global hash lock scheme is where we can hash addresses
>>> directly into a static locking table. The lock table is created
>>> _before_ any program logic is executed.
>>>
>>> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ
>>>
>>>
>>>> Also, some global object could start up a thread in its constructor.
>>>
>>> YIKES! Shit. I have had to debug other peoples code that did this.
>>> Many points of errors... One was a rather common peach of a bug. The
>>> constructor would create a thread that would in turn call into a
>>> virtual function and start using the object before its constructor was
>>> completed. A massive race condition, nasty ones!
>>>
>>
>> Yes, such a thread needs to understand that the system isn't fully
>> configured. And yes, a base class creating a thread needs that thread to
>> understand that the object isn't fully created yet and do something to
>> handle that issue (which likely requires some help from the most derived
>> class).
>
>I actually got to a point where I said no creating threads in
>constructors! I have seen to many problems. Create the object _first_,
>then expose it to a thread, or create a thread that works with the
>_fully_ constructed object. The types of race conditions I have had to
>deal with wrt objects creating threads in constructors have tended to be
>rather nasty in nature...
The race condition is pretty easy to resolve. Turn thread initialization
into a two-phase operation.
When we have an object that requires its own thread, it will inherit
from a base class called c_thread. The constructor for c_thread will
create the thread which eventually executes the objects 'run' function. The
pthread_create call starts the thread executing at the static function
c_thread::run(void *obj), where the argument is a pointer to the object
itself.
That static function sets the process name (prctl(PR_SET_NAME)) and
then waits on a pthread_cond_t (thread_initialized) declared as a data member of
c_thread.
Meanwhile, the derived object constructor runs in the original thread after the c_thread
constructor returns and initializes the object. Once the object is fully
initialized (which may happen in the constructor, or may happen
at some later point in time during program startup), the c_thread::run
method condition variable (thread_initialized) is signaled and the
static ::run function transfers control to the derived class virtual ::run
function.
/**
* Static pthread start function. Invokes thread specific run virtual
* function.
*
* @param arg The class object pointer passed in from the pthread_create.
*/
void *
c_thread::run(void *arg)
{
c_thread *tp = (c_thread *)arg;
int diag;
pthread_mutex_lock(&tp->t_threadlock);
while (!tp->t_thread_initialized) {
pthread_cond_wait(&tp->t_ready, &tp->t_threadlock);
}
pthread_mutex_unlock(&tp->t_threadlock);
diag = prctl(PR_SET_NAME, tp->t_thread_name, NULL, NULL, NULL, NULL);
if (diag == -1) {
tp->t_logger->log("Unable to set thread name: %s\n", strerror(errno));
}
tp->t_running = true;
tp->run();
tp->t_running = false;
return NULL;
}
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-23 12:35 -0700 |
| Message-ID | <uenel9$ttb5$1@dont-email.me> |
| In reply to | #91587 |
On 9/7/2023 2:13 PM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 9/7/2023 12:52 PM, Richard Damon wrote:
>>> On 9/7/23 12:20 PM, Chris M. Thomasson wrote:
>>>> On 9/7/2023 11:06 AM, Richard Damon wrote:
>>>>> On 9/7/23 10:27 AM, Scott Lurndal wrote:
>>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>>> Am 07.09.2023 um 16:44 schrieb Pavel:
>>>>>>>
>>>>>>>> How so? Waiters will wait for the time of initialization.
>>>>>>>> The initializing thread will be yielded ...
>>>>>>>
>>>>>>> Initializing is usually much faster than a whole timeslice,
>>>>>>> so yielding would be incacceptabel. That's just a stupid idea.
>>>>>>
>>>>>> So tell us, on which operating systems will there be more than
>>>>>> one thread running when application static objects are
>>>>>> initialized (which happens generally before the application
>>>>>> 'main' function is called, and thus before the application
>>>>>> has a chance to create any threads)?
>>>>>
>>>>> While GLOBAL static objects get initialized before main starts,
>>>>> function local static objects don't get initialized until the first
>>>>> call of the function. These will need some synchronization if the
>>>>> function is called from multiple threads at "the same time".
>>>>
>>>> A simple global hash lock scheme is where we can hash addresses
>>>> directly into a static locking table. The lock table is created
>>>> _before_ any program logic is executed.
>>>>
>>>> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/wwYQCG2hAwAJ
>>>>
>>>>
>>>>> Also, some global object could start up a thread in its constructor.
>>>>
>>>> YIKES! Shit. I have had to debug other peoples code that did this.
>>>> Many points of errors... One was a rather common peach of a bug. The
>>>> constructor would create a thread that would in turn call into a
>>>> virtual function and start using the object before its constructor was
>>>> completed. A massive race condition, nasty ones!
>>>>
>>>
>>> Yes, such a thread needs to understand that the system isn't fully
>>> configured. And yes, a base class creating a thread needs that thread to
>>> understand that the object isn't fully created yet and do something to
>>> handle that issue (which likely requires some help from the most derived
>>> class).
>>
>> I actually got to a point where I said no creating threads in
>> constructors! I have seen to many problems. Create the object _first_,
>> then expose it to a thread, or create a thread that works with the
>> _fully_ constructed object. The types of race conditions I have had to
>> deal with wrt objects creating threads in constructors have tended to be
>> rather nasty in nature...
>
> The race condition is pretty easy to resolve. Turn thread initialization
> into a two-phase operation.
>
> When we have an object that requires its own thread, it will inherit
> from a base class called c_thread. The constructor for c_thread will
> create the thread which eventually executes the objects 'run' function. The
> pthread_create call starts the thread executing at the static function
> c_thread::run(void *obj), where the argument is a pointer to the object
> itself.
>
> That static function sets the process name (prctl(PR_SET_NAME)) and
> then waits on a pthread_cond_t (thread_initialized) declared as a data member of
> c_thread.
>
> Meanwhile, the derived object constructor runs in the original thread after the c_thread
> constructor returns and initializes the object. Once the object is fully
> initialized (which may happen in the constructor, or may happen
> at some later point in time during program startup), the c_thread::run
> method condition variable (thread_initialized) is signaled and the
> static ::run function transfers control to the derived class virtual ::run
> function.
>
> /**
> * Static pthread start function. Invokes thread specific run virtual
> * function.
> *
> * @param arg The class object pointer passed in from the pthread_create.
> */
> void *
> c_thread::run(void *arg)
> {
> c_thread *tp = (c_thread *)arg;
> int diag;
>
> pthread_mutex_lock(&tp->t_threadlock);
> while (!tp->t_thread_initialized) {
> pthread_cond_wait(&tp->t_ready, &tp->t_threadlock);
> }
> pthread_mutex_unlock(&tp->t_threadlock);
>
> diag = prctl(PR_SET_NAME, tp->t_thread_name, NULL, NULL, NULL, NULL);
> if (diag == -1) {
> tp->t_logger->log("Unable to set thread name: %s\n", strerror(errno));
> }
>
> tp->t_running = true;
> tp->run();
> tp->t_running = false;
>
> return NULL;
> }
Actually, I like to ensure that the "object" is 100% initialized before
any thread is able to acquire a pointer to it. A little proxy object in
C++ tends to work fine for me:
template<typename T>
struct thread_proxy
{
T m_object;
std::thread m_thread;
};
We can launch the thread in the constructor of thread_proxy<T>.
thread_proxy<T>::m_object is 100% fully initialized before the thread is
created. Simple and works for me. Fair enough?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-07 20:24 +0200 |
| Message-ID | <udd4gg$334c7$1@dont-email.me> |
| In reply to | #91576 |
Am 07.09.2023 um 19:27 schrieb Scott Lurndal:
> So tell us, on which operating systems will there be more
> than one thread running when application static objects are
> initialized (which happens generally before the application
> 'main' function is called, and thus before the application
> has a chance to create any threads)?
I've shown with my code that each static object gets its own mutex
with MSVC, libstdc++ and libc++. Here it is again in a simplified
version:
#include <iostream>
#include <thread>
#include <vector>
using namespace std;
int main()
{
struct SleepAtInitialize
{
SleepAtInitialize()
{
this_thread::sleep_for( 1s );
}
};
auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>, auto
fn )
{
((fn.template operator ()<Indices>()), ...);
};
constexpr unsigned N_THREADS = 10;
vector<jthread> threads;
threads.reserve( N_THREADS );
unroll( make_index_sequence<N_THREADS>(),
[&]<unsigned Thread>()
{
threads.emplace_back(
[&]<unsigned IObj>( integral_constant<unsigned, IObj> )
{
static SleepAtInitialize guard;
}, integral_constant<unsigned, Thread>() );
} );
}
The code runs about one second with all three implementations,
so ther's a mutex per statically initialized object.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-07 20:53 -0400 |
| Message-ID | <wguKM.698884$xMqa.357246@fx12.iad> |
| In reply to | #91575 |
Bonita Montero wrote:
> Am 07.09.2023 um 16:44 schrieb Pavel:
>
>> How so? Waiters will wait for the time of initialization.
>> The initializing thread will be yielded ...
>
> Initializing is usually much faster than a whole timeslice,
> so yielding would be incacceptabel. That's just a stupid idea.
Mutex makes thread waiting for initialization not runnable. Yield leaves
it runnable. Therefore, waking up a thread that acquired the mutex is
actually slower than the time needed by thread that yielded to get
running again. This is regardless of whether initializing is slow or fast.
>
>> try_lock in a loop with a sleep or yield wouldn't fail. ...
>
> Do you really think someone would accept spinning with that ?
I don't have to think about this because I know many do.
> This means that an initializing thread which is scheduled away
> while holding the mutex might keep other threads spinning for
> a long time.
No, it can be scheduled away only momentarily because the waiting
threads will relinquish the CPU instantly after being scheduled.
>
>> Regardless, your argument assumes too much C++-morphism in the
>> implementation whereas the implementation can use any platform
>> -specific approach available to it. E.g. pthread_once on Linux
>> does not fail if given valid arguments ...
>
> pthread_once could be implemented with a single central semaphore
pthread_once takes a statically-initialized pthread_once_t "once
control" that the calling code must supply. It is against the purpose of
pthread_once to wait for a single central semaphore. On the opposite,
the goal is to let the client code control the concurrency by selecting
how many "once control" they want to use.
> for
> all operations and if the implementers know that the synchronization
> itself doesn't fail and the semphore is pre-allocated by the runtime
> it's possible to survive that synchronization without error.
correct. My point exactly.
> But check that code:
>
> #include <iostream>
> #include <thread>
> #include <vector>
>
> using namespace std;
>
> template<unsigned Thread>
> struct SleepAtInitialize
> {
> SleepAtInitialize()
> {
> this_thread::sleep_for( 1s );
> }
> };
>
> int main()
> {
> auto unroll = []<size_t ... Indices>( index_sequence<Indices ...>,
> auto fn )
> {
> ((fn.template operator ()<Indices>()), ...);
> };
> constexpr unsigned N_THREADS = 10;
> vector<jthread> threads;
> threads.reserve( N_THREADS );
> unroll( make_index_sequence<N_THREADS>(),
> [&]<unsigned Thread>()
> {
> threads.emplace_back(
> [&]<unsigned IObj>( integral_constant<unsigned, IObj> )
> {
> static SleepAtInitialize<IObj> guard;
> }, integral_constant<unsigned, Thread>() );
> } );
>
> }
>
> This code runs with individual mutexes per object, i.e. the time
> taken is about one second (with MSVC, libc++ and libstdc++). So
> when individual mutexes are used the initialization may fail.
See above for why pthread_once implementation should also take one
second with the individual pthread_once_t once controls per object.
>
>> Correct, the above was wrong. But initialization can catch and try
>> again. ...
>
> That a bumbler solution.
mutex locking does not fail for no reason. In practice on Linux if the
mutex is in the committed memory and is propertly prioritized and
permissioned and is non-robust (all of which one should assume to be
true for a mutex used by a C++ implementation for initialization) I am
unaware of any reason for why non-timed locking may fail other than
deadlock detection. C++ behavior for the scenario when static
initialization deadlocks is unspecified so the above solution is no
better or worse than any other.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-08 07:37 +0200 |
| Message-ID | <udebu2$3bknb$1@dont-email.me> |
| In reply to | #91589 |
Am 08.09.2023 um 02:53 schrieb Pavel: > Bonita Montero wrote: >> so yielding would be incacceptabel. That's just a stupid idea. > Mutex makes thread waiting for initialization not runnable. Yield leaves > it runnable. Therefore, waking up a thread that acquired the mutex is > actually slower than the time needed by thread that yielded to get > running again. This is regardless of whether initializing is slow or fast. However, using sth. like yield is unacceptably slow. > No, it can be scheduled away only momentarily because the waiting > threads will relinquish the CPU instantly after being scheduled. The thread might be scheduled away many timeslices - that's unacceptable. > See above for why pthread_once implementation should also take one > second with the individual pthread_once_t once controls per object. As you can see from my source the common runtimes use a mutex per object. This creation may fail. > mutex locking does not fail for no reason. ... It's like when a memory allocation would fail and you would spin until it doesn't fail again. That's also unacceptable.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-08 14:54 -0400 |
| Message-ID | <X5KKM.218705$ftCb.30173@fx34.iad> |
| In reply to | #91592 |
Bonita Montero wrote: > Am 08.09.2023 um 02:53 schrieb Pavel: > >> Bonita Montero wrote: > >>> so yielding would be incacceptabel. That's just a stupid idea. > >> Mutex makes thread waiting for initialization not runnable. Yield >> leaves it runnable. Therefore, waking up a thread that acquired the >> mutex is actually slower than the time needed by thread that yielded >> to get running again. This is regardless of whether initializing is >> slow or fast. > > However, using sth. like yield is unacceptably slow. As per the above yield-based waiting for initialization is not slower than mutex-based. Hence, this "unacceptably slow is nonsense. > >> No, it can be scheduled away only momentarily because the waiting >> threads will relinquish the CPU instantly after being scheduled. > > The thread might be scheduled away many timeslices - A thread that waits for the contended mutex is, upon locking the mutex, scheduled identically to yield so no difference with mutex > that's > unacceptable. as per the above, this "unacceptale" is nonsense, too. > > >> See above for why pthread_once implementation should also take one >> second with the individual pthread_once_t once controls per object. > > As you can see from my source the common runtimes use a mutex per > object. On the opposite, I can see in glibc source code that pthread_once for linux (which is most common) does not use mutex. There is no "creation", pthread_once_t is an int. > This creation may fail. as per the above, there is nothing to fail unless someone decides to allocate the int in free memory -- which is not done for static initialization. > >> mutex locking does not fail for no reason. ... > > It's like when a memory allocation would fail and you would > spin until it doesn't fail again. as per the above, there is nothing to fail unless someone decides to allocate the int in free memory -- which is not done for static initialization. > That's also unacceptable. as per the above, this "unacceptale" is nonsense, too.
[toc] | [prev] | [next] | [standalone]
Page 1 of 34 [1] 2 3 … 34 Next page →
Back to top | Article view | comp.lang.c++
csiph-web