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 27 of 34 — ← Prev page 1 … 25 26 [27] 28 29 … 34 Next page →
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2023-09-24 12:46 -0400 |
| Message-ID | <7b90d532-4d13-3d4c-f9d6-3d9c964c988c@removeyourself.dontspam.yahoo> |
| In reply to | #92044 |
Bonita Montero wrote: > Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: > >> A possible design is that each *thread* has a wait semaphore. > > You'd have to register the binary semaphore and register as a waiter in > one atomic step. You could do that with a DCAS'd ring, but you coudn't > atomically update the link pointers of the other nodes at the same > time you update the roots link pointers. And you would have the deallo- > cation poblem, i.e. the memory of your object may never be deallocated. > Show me your implementation ! > It's ridiculous because mutex are a cheap resource. Cheap as compared to what? How is a mutex "cheaper" than other synchronization primitives? Also, what exactly mutex operation(s) is/are cheap? Also, what exactly mutex type is cheap? On what platform? A blanket statement is never entirely true or false, nothing can be "ridiculous" because of it. > And if such imple- > mentation would be possible the standard shouldn't mandate it since > not every platform has a DCAS. >
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-24 17:04 +0000 |
| Message-ID | <20230924092501.340@kylheku.com> |
| In reply to | #92044 |
On 2023-09-24, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: > >> A possible design is that each *thread* has a wait semaphore. > > You'd have to register the binary semaphore and register as a waiter in > one atomic step. You could do that with a DCAS'd ring, but you coudn't > atomically update the link pointers of the other nodes at the same > time you update the roots link pointers. And you would have the deallo- > cation poblem, i.e. the memory of your object may never be deallocated. Now you're just throwing together words you don't understand. > Show me your implementation ! E.g. old LinuxThreads in glibc, circa 2000: https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe The low level __pthread_lock and __pthread_unlock functions maintain a queue, using a single-word atomic CAS. There are suspend() and resume() functions for the waiting; they are elsewhere. If you look in restart.h you can see that those operations are defined in two different ways, both of which use signals (not a semaphore per thread). A suspending thread waits for the arrival of a signal, resume is done by sending a signal. That's kind of semaphore-like; and POSIX real-time signals can even queue up, like a counting sem. > It's ridiculous because mutex are a cheap resource. And if such imple- > mentation would be possible the standard shouldn't mandate it since > not every platform has a DCAS. Things can be done in ways you havn't thought about. Atomic operations aren't required to achieve mutual exclusion among processors that share memory. As someone continually insisting on having expertise in concurrency, you must be familiar with the research work of Leslie Lamport? For instance, the paper _A Fast Mutual Exclusion Algorithm_ [1985]. Abstract: "A new solution to the mutual exclusion problem is presented that, in the absence of contention, requires only seven memory accesses. It assumes atomic reads and atomic writes to shared registers." Snipeet from Introduction which gives a clue as to the motivation: "Recently, there has arisen interest in building shared-memory multiprocessor computers by connecting standard processors and memories, with as little modification to the hardware as possible. Because ordinary sequential processors and memories do not have atomic test-and-set operations, it is worth investigating whether shared-memory mutual exclusion algorithms are a practical alternative." -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-25 22:52 -0700 |
| Message-ID | <uetrjn$2car5$1@dont-email.me> |
| In reply to | #92074 |
On 9/24/2023 10:04 AM, Kaz Kylheku wrote: > On 2023-09-24, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: >> >>> A possible design is that each *thread* has a wait semaphore. >> >> You'd have to register the binary semaphore and register as a waiter in >> one atomic step. You could do that with a DCAS'd ring, but you coudn't >> atomically update the link pointers of the other nodes at the same >> time you update the roots link pointers. And you would have the deallo- >> cation poblem, i.e. the memory of your object may never be deallocated. > > Now you're just throwing together words you don't understand. > >> Show me your implementation ! > > E.g. old LinuxThreads in glibc, circa 2000: > > https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe > > The low level __pthread_lock and __pthread_unlock functions maintain a > queue, using a single-word atomic CAS. > > There are suspend() and resume() functions for the waiting; > they are elsewhere. > > If you look in restart.h you can see that those operations are defined > in two different ways, both of which use signals (not a semaphore per > thread). A suspending thread waits for the arrival of a signal, > resume is done by sending a signal. That's kind of semaphore-like; > and POSIX real-time signals can even queue up, like a counting sem. > >> It's ridiculous because mutex are a cheap resource. And if such imple- >> mentation would be possible the standard shouldn't mandate it since >> not every platform has a DCAS. > > Things can be done in ways you havn't thought about. > > Atomic operations aren't required to achieve mutual exclusion among > processors that share memory. > > As someone continually insisting on having expertise in concurrency, > you must be familiar with the research work of Leslie Lamport? Iirc, that uses atomic loads, stores and membars. Iirc, it requires a #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit membar on the x86. MFENCE, or XCHG which has the lock prefix automatically asserted. Humm... There is a way to get around that bastard #StoreLoad membar... It uses an async sync setup. The funny thing is that Windows has a API that can be used to actually implement it! Try to think of a so called, remote memory barrier, in a sense: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers There is a way to use this to get an async mutex that is kind of sort of akin to a read write mutex. Basically, the mutex is broken down into two parts. One that represents accesses that _very_ frequently called upon. The other one is used rather rarely. This is the async nature that can be exploited in rather interesting ways. I implemented some in the past with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used to implement other rather exotic sync schemes. They have very excellent performance for certain workloads. Actually, there is a way to use it to get a RCU in userspace and/or hazard pointers without any explicit #StoreLoad membars. > > For instance, the paper _A Fast Mutual Exclusion Algorithm_ [1985]. > > Abstract: > > "A new solution to the mutual exclusion problem is presented that, in the > absence of contention, requires only seven memory accesses. It assumes > atomic reads and atomic writes to shared registers." > > Snipeet from Introduction which gives a clue as to the motivation: > > "Recently, there has arisen interest in building shared-memory > multiprocessor computers by connecting standard processors and > memories, with as little modification to the hardware as possible. > Because ordinary sequential processors and memories do not have atomic > test-and-set operations, it is worth investigating whether > shared-memory mutual exclusion algorithms are a practical alternative." >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-25 23:08 -0700 |
| Message-ID | <uetshq$2cf69$1@dont-email.me> |
| In reply to | #92127 |
On 9/25/2023 10:52 PM, Chris M. Thomasson wrote: > On 9/24/2023 10:04 AM, Kaz Kylheku wrote: >> On 2023-09-24, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: >>> >>>> A possible design is that each *thread* has a wait semaphore. >>> >>> You'd have to register the binary semaphore and register as a waiter in >>> one atomic step. You could do that with a DCAS'd ring, but you coudn't >>> atomically update the link pointers of the other nodes at the same >>> time you update the roots link pointers. And you would have the deallo- >>> cation poblem, i.e. the memory of your object may never be deallocated. >> >> Now you're just throwing together words you don't understand. >> >>> Show me your implementation ! >> >> E.g. old LinuxThreads in glibc, circa 2000: >> >> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe >> >> The low level __pthread_lock and __pthread_unlock functions maintain a >> queue, using a single-word atomic CAS. >> >> There are suspend() and resume() functions for the waiting; >> they are elsewhere. >> >> If you look in restart.h you can see that those operations are defined >> in two different ways, both of which use signals (not a semaphore per >> thread). A suspending thread waits for the arrival of a signal, >> resume is done by sending a signal. That's kind of semaphore-like; >> and POSIX real-time signals can even queue up, like a counting sem. >> >>> It's ridiculous because mutex are a cheap resource. And if such imple- >>> mentation would be possible the standard shouldn't mandate it since >>> not every platform has a DCAS. >> >> Things can be done in ways you havn't thought about. >> >> Atomic operations aren't required to achieve mutual exclusion among >> processors that share memory. >> >> As someone continually insisting on having expertise in concurrency, >> you must be familiar with the research work of Leslie Lamport? > > Iirc, that uses atomic loads, stores and membars. Iirc, it requires a > #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit > membar on the x86. MFENCE, or XCHG which has the lock prefix > automatically asserted. Humm... There is a way to get around that > bastard #StoreLoad membar... It uses an async sync setup. The funny > thing is that Windows has a API that can be used to actually implement > it! Try to think of a so called, remote memory barrier, in a sense: > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers > > There is a way to use this to get an async mutex that is kind of sort of > akin to a read write mutex. Basically, the mutex is broken down into two > parts. One that represents accesses that _very_ frequently called upon. > The other one is used rather rarely. This is the async nature that can > be exploited in rather interesting ways. I implemented some in the past > with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used > to implement other rather exotic sync schemes. They have very excellent > performance for certain workloads. Actually, there is a way to use it to > get a RCU in userspace and/or hazard pointers without any explicit > #StoreLoad membars. The idea is that the "fast" part of the mutex allows threads to access shared data without using any memory barriers, "usually" read only... The "slow" part of the async mutex checks some things, reports its intent then issues a FlushProcessWriteBuffers to sync up with the fast part. This is basically akin to RCU, in a sense. Have you experimented with the rather "exotic" async mutexes before? RCU is geared toward giving reads full speed ahead captain, and writers are sort of second class citizens. So, it's also async in a way... There is a way to use FlushProcessWriteBuffers to create a "quiescent" state, ala RCU, wrt memory visibility. There is an interesting paper that described a technique, iirc, its called QPI or something. That tried to "abuse" an x86 to generate remote memory barriers. Iirc, they intentionally use unaligned accesses to trigger a BUS lock. I need to find that damn paper! :^) I read it before! damn it. Thanks for sparking my mind on this. It's been a while Kaz. :^) > > > >> >> For instance, the paper _A Fast Mutual Exclusion Algorithm_ [1985]. >> >> Abstract: >> >> "A new solution to the mutual exclusion problem is presented that, >> in the >> absence of contention, requires only seven memory accesses. It >> assumes >> atomic reads and atomic writes to shared registers." >> >> Snipeet from Introduction which gives a clue as to the motivation: >> >> "Recently, there has arisen interest in building shared-memory >> multiprocessor computers by connecting standard processors and >> memories, with as little modification to the hardware as possible. >> Because ordinary sequential processors and memories do not have >> atomic >> test-and-set operations, it is worth investigating whether >> shared-memory mutual exclusion algorithms are a practical >> alternative." >> >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-09-26 09:05 -0700 |
| Message-ID | <e01f389c-3f23-47dc-89cd-a21038c6592an@googlegroups.com> |
| In reply to | #92127 |
On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote: > On 9/24/2023 10:04 AM, Kaz Kylheku wrote: > > On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote: > >> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: > >> > >>> A possible design is that each *thread* has a wait semaphore. > >> > >> You'd have to register the binary semaphore and register as a waiter in > >> one atomic step. You could do that with a DCAS'd ring, but you coudn't > >> atomically update the link pointers of the other nodes at the same > >> time you update the roots link pointers. And you would have the deallo- > >> cation poblem, i.e. the memory of your object may never be deallocated. > > > > Now you're just throwing together words you don't understand. > > > >> Show me your implementation ! > > > > E.g. old LinuxThreads in glibc, circa 2000: > > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe > > > > The low level __pthread_lock and __pthread_unlock functions maintain a > > queue, using a single-word atomic CAS. > > > > There are suspend() and resume() functions for the waiting; > > they are elsewhere. > > > > If you look in restart.h you can see that those operations are defined > > in two different ways, both of which use signals (not a semaphore per > > thread). A suspending thread waits for the arrival of a signal, > > resume is done by sending a signal. That's kind of semaphore-like; > > and POSIX real-time signals can even queue up, like a counting sem. > > > >> It's ridiculous because mutex are a cheap resource. And if such imple- > >> mentation would be possible the standard shouldn't mandate it since > >> not every platform has a DCAS. > > > > Things can be done in ways you havn't thought about. > > > > Atomic operations aren't required to achieve mutual exclusion among > > processors that share memory. > > > > As someone continually insisting on having expertise in concurrency, > > you must be familiar with the research work of Leslie Lamport? > > Iirc, that uses atomic loads, stores and membars. Iirc, it requires a > #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit > membar on the x86. MFENCE, or XCHG which has the lock prefix > automatically asserted. Humm... There is a way to get around that > bastard #StoreLoad membar... It uses an async sync setup. The funny > thing is that Windows has a API that can be used to actually implement > it! Try to think of a so called, remote memory barrier, in a sense: > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers > > There is a way to use this to get an async mutex that is kind of sort of > akin to a read write mutex. Basically, the mutex is broken down into two > parts. One that represents accesses that _very_ frequently called upon. > The other one is used rather rarely. This is the async nature that can > be exploited in rather interesting ways. I implemented some in the past > with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used > to implement other rather exotic sync schemes. They have very excellent > performance for certain workloads. Actually, there is a way to use it to > get a RCU in userspace and/or hazard pointers without any explicit > #StoreLoad membars. > > I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude slower than #StoreLoad membar. I could be wrong, of course, the function is close to undocumented. > > > > > For instance, the paper _A Fast Mutual Exclusion Algorithm_ [1985]. > > > > Abstract: > > > > "A new solution to the mutual exclusion problem is presented that, in the > > absence of contention, requires only seven memory accesses. It assumes > > atomic reads and atomic writes to shared registers." > > > > Snipeet from Introduction which gives a clue as to the motivation: > > > > "Recently, there has arisen interest in building shared-memory > > multiprocessor computers by connecting standard processors and > > memories, with as little modification to the hardware as possible. > > Because ordinary sequential processors and memories do not have atomic > > test-and-set operations, it is worth investigating whether > > shared-memory mutual exclusion algorithms are a practical alternative." > >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-26 12:58 -0700 |
| Message-ID | <uevd5n$2ligo$1@dont-email.me> |
| In reply to | #92147 |
On 9/26/2023 9:05 AM, Michael S wrote: > On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote: >> On 9/24/2023 10:04 AM, Kaz Kylheku wrote: >>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote: >>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: >>>> >>>>> A possible design is that each *thread* has a wait semaphore. >>>> >>>> You'd have to register the binary semaphore and register as a waiter in >>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't >>>> atomically update the link pointers of the other nodes at the same >>>> time you update the roots link pointers. And you would have the deallo- >>>> cation poblem, i.e. the memory of your object may never be deallocated. >>> >>> Now you're just throwing together words you don't understand. >>> >>>> Show me your implementation ! >>> >>> E.g. old LinuxThreads in glibc, circa 2000: >>> >>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe >>> >>> The low level __pthread_lock and __pthread_unlock functions maintain a >>> queue, using a single-word atomic CAS. >>> >>> There are suspend() and resume() functions for the waiting; >>> they are elsewhere. >>> >>> If you look in restart.h you can see that those operations are defined >>> in two different ways, both of which use signals (not a semaphore per >>> thread). A suspending thread waits for the arrival of a signal, >>> resume is done by sending a signal. That's kind of semaphore-like; >>> and POSIX real-time signals can even queue up, like a counting sem. >>> >>>> It's ridiculous because mutex are a cheap resource. And if such imple- >>>> mentation would be possible the standard shouldn't mandate it since >>>> not every platform has a DCAS. >>> >>> Things can be done in ways you havn't thought about. >>> >>> Atomic operations aren't required to achieve mutual exclusion among >>> processors that share memory. >>> >>> As someone continually insisting on having expertise in concurrency, >>> you must be familiar with the research work of Leslie Lamport? >> >> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a >> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit >> membar on the x86. MFENCE, or XCHG which has the lock prefix >> automatically asserted. Humm... There is a way to get around that >> bastard #StoreLoad membar... It uses an async sync setup. The funny >> thing is that Windows has a API that can be used to actually implement >> it! Try to think of a so called, remote memory barrier, in a sense: >> >> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers >> >> There is a way to use this to get an async mutex that is kind of sort of >> akin to a read write mutex. Basically, the mutex is broken down into two >> parts. One that represents accesses that _very_ frequently called upon. >> The other one is used rather rarely. This is the async nature that can >> be exploited in rather interesting ways. I implemented some in the past >> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used >> to implement other rather exotic sync schemes. They have very excellent >> performance for certain workloads. Actually, there is a way to use it to >> get a RCU in userspace and/or hazard pointers without any explicit >> #StoreLoad membars. >> >> > > I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude > slower than #StoreLoad membar. I could be wrong, of course, the function > is close to undocumented. FlushProcessWriteBuffers() can be used to gain a quiescent state wrt memory visibility for some exotic async algorithms, it is called in certain places and is RARE. However, on the other hand, having to use a #StoreLoad membar on the fast path is not good. Keep in mind that this is meant to handle a store followed by a load to another location scenario. We need to honor the #StoreLoad relationship for this type of setup for these types of algorithms. For instance, hazard pointers require a #StoreLoad, however there is a way to eliminate them using some special magic wrt RCU... My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard pointers. Now, keep in mind that these are very "specialized" algorithms that try to make certain workloads MUCH faster and way more efficient. They work for that. Also, keep in mind that a normal mutex does not require #StoreLoad. Only acquire and release: acquire = #LoadStore | #LoadLoad release = #LoadStore | #StoreStore In SPARC parlance. For instance, an atomic store on x86 automatically implies release. Btw, have you ever worked with SPARC in RMO mode? Its fun because its so weak. I still need to find that old paper called QPI, if I remember correctly. It should still be out there. I will try to find it sometime today. It think is was from Dice wrt a Java VM. David Dice? Damn I cannot remember it right now. Sorry. ;^o [...]
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-09-26 13:58 -0700 |
| Message-ID | <5694c62a-9ebc-434d-8496-2475ed56d7b4n@googlegroups.com> |
| In reply to | #92158 |
On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote: > On 9/26/2023 9:05 AM, Michael S wrote: > > On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote: > >> On 9/24/2023 10:04 AM, Kaz Kylheku wrote: > >>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote: > >>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: > >>>> > >>>>> A possible design is that each *thread* has a wait semaphore. > >>>> > >>>> You'd have to register the binary semaphore and register as a waiter in > >>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't > >>>> atomically update the link pointers of the other nodes at the same > >>>> time you update the roots link pointers. And you would have the deallo- > >>>> cation poblem, i.e. the memory of your object may never be deallocated. > >>> > >>> Now you're just throwing together words you don't understand. > >>> > >>>> Show me your implementation ! > >>> > >>> E.g. old LinuxThreads in glibc, circa 2000: > >>> > >>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe > >>> > >>> The low level __pthread_lock and __pthread_unlock functions maintain a > >>> queue, using a single-word atomic CAS. > >>> > >>> There are suspend() and resume() functions for the waiting; > >>> they are elsewhere. > >>> > >>> If you look in restart.h you can see that those operations are defined > >>> in two different ways, both of which use signals (not a semaphore per > >>> thread). A suspending thread waits for the arrival of a signal, > >>> resume is done by sending a signal. That's kind of semaphore-like; > >>> and POSIX real-time signals can even queue up, like a counting sem. > >>> > >>>> It's ridiculous because mutex are a cheap resource. And if such imple- > >>>> mentation would be possible the standard shouldn't mandate it since > >>>> not every platform has a DCAS. > >>> > >>> Things can be done in ways you havn't thought about. > >>> > >>> Atomic operations aren't required to achieve mutual exclusion among > >>> processors that share memory. > >>> > >>> As someone continually insisting on having expertise in concurrency, > >>> you must be familiar with the research work of Leslie Lamport? > >> > >> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a > >> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit > >> membar on the x86. MFENCE, or XCHG which has the lock prefix > >> automatically asserted. Humm... There is a way to get around that > >> bastard #StoreLoad membar... It uses an async sync setup. The funny > >> thing is that Windows has a API that can be used to actually implement > >> it! Try to think of a so called, remote memory barrier, in a sense: > >> > >> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers > >> > >> There is a way to use this to get an async mutex that is kind of sort of > >> akin to a read write mutex. Basically, the mutex is broken down into two > >> parts. One that represents accesses that _very_ frequently called upon. > >> The other one is used rather rarely. This is the async nature that can > >> be exploited in rather interesting ways. I implemented some in the past > >> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used > >> to implement other rather exotic sync schemes. They have very excellent > >> performance for certain workloads. Actually, there is a way to use it to > >> get a RCU in userspace and/or hazard pointers without any explicit > >> #StoreLoad membars. > >> > >> > > > > I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude > > slower than #StoreLoad membar. I could be wrong, of course, the function > > is close to undocumented. > FlushProcessWriteBuffers() can be used to gain a quiescent state wrt > memory visibility for some exotic async algorithms, it is called in > certain places and is RARE. However, on the other hand, having to use a > #StoreLoad membar on the fast path is not good. Keep in mind that this > is meant to handle a store followed by a load to another location > scenario. We need to honor the #StoreLoad relationship for this type of > setup for these types of algorithms. For instance, hazard pointers > require a #StoreLoad, however there is a way to eliminate them using > some special magic wrt RCU... > > My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard > pointers. Now, keep in mind that these are very "specialized" algorithms > that try to make certain workloads MUCH faster and way more efficient. > They work for that. > > Also, keep in mind that a normal mutex does not require #StoreLoad. Only > acquire and release: > > acquire = #LoadStore | #LoadLoad > release = #LoadStore | #StoreStore > > In SPARC parlance. For instance, an atomic store on x86 automatically > implies release. Btw, have you ever worked with SPARC in RMO mode? Its > fun because its so weak. > We discussed it already. I don't think that SPARCv9 RMO hardware ever existed and you failed to convince me otherwise. As to weakness, I don't think that by specification it is weaker than IPF, may be not even weaker than POWER. Certainly stronger than Alpha. But it does not matter since it does not exist. > I still need to find that old paper called QPI, if I remember correctly. > It should still be out there. I will try to find it sometime today. > > It think is was from Dice wrt a Java VM. David Dice? Damn I cannot > remember it right now. Sorry. ;^o > > > [...]
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-26 14:06 -0700 |
| Message-ID | <uevh5g$2m8qq$1@dont-email.me> |
| In reply to | #92164 |
On 9/26/2023 1:58 PM, Michael S wrote: > On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote: >> On 9/26/2023 9:05 AM, Michael S wrote: >>> On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote: >>>> On 9/24/2023 10:04 AM, Kaz Kylheku wrote: >>>>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote: >>>>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: >>>>>> >>>>>>> A possible design is that each *thread* has a wait semaphore. >>>>>> >>>>>> You'd have to register the binary semaphore and register as a waiter in >>>>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't >>>>>> atomically update the link pointers of the other nodes at the same >>>>>> time you update the roots link pointers. And you would have the deallo- >>>>>> cation poblem, i.e. the memory of your object may never be deallocated. >>>>> >>>>> Now you're just throwing together words you don't understand. >>>>> >>>>>> Show me your implementation ! >>>>> >>>>> E.g. old LinuxThreads in glibc, circa 2000: >>>>> >>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe >>>>> >>>>> The low level __pthread_lock and __pthread_unlock functions maintain a >>>>> queue, using a single-word atomic CAS. >>>>> >>>>> There are suspend() and resume() functions for the waiting; >>>>> they are elsewhere. >>>>> >>>>> If you look in restart.h you can see that those operations are defined >>>>> in two different ways, both of which use signals (not a semaphore per >>>>> thread). A suspending thread waits for the arrival of a signal, >>>>> resume is done by sending a signal. That's kind of semaphore-like; >>>>> and POSIX real-time signals can even queue up, like a counting sem. >>>>> >>>>>> It's ridiculous because mutex are a cheap resource. And if such imple- >>>>>> mentation would be possible the standard shouldn't mandate it since >>>>>> not every platform has a DCAS. >>>>> >>>>> Things can be done in ways you havn't thought about. >>>>> >>>>> Atomic operations aren't required to achieve mutual exclusion among >>>>> processors that share memory. >>>>> >>>>> As someone continually insisting on having expertise in concurrency, >>>>> you must be familiar with the research work of Leslie Lamport? >>>> >>>> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a >>>> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit >>>> membar on the x86. MFENCE, or XCHG which has the lock prefix >>>> automatically asserted. Humm... There is a way to get around that >>>> bastard #StoreLoad membar... It uses an async sync setup. The funny >>>> thing is that Windows has a API that can be used to actually implement >>>> it! Try to think of a so called, remote memory barrier, in a sense: >>>> >>>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers >>>> >>>> There is a way to use this to get an async mutex that is kind of sort of >>>> akin to a read write mutex. Basically, the mutex is broken down into two >>>> parts. One that represents accesses that _very_ frequently called upon. >>>> The other one is used rather rarely. This is the async nature that can >>>> be exploited in rather interesting ways. I implemented some in the past >>>> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used >>>> to implement other rather exotic sync schemes. They have very excellent >>>> performance for certain workloads. Actually, there is a way to use it to >>>> get a RCU in userspace and/or hazard pointers without any explicit >>>> #StoreLoad membars. >>>> >>>> >>> >>> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude >>> slower than #StoreLoad membar. I could be wrong, of course, the function >>> is close to undocumented. >> FlushProcessWriteBuffers() can be used to gain a quiescent state wrt >> memory visibility for some exotic async algorithms, it is called in >> certain places and is RARE. However, on the other hand, having to use a >> #StoreLoad membar on the fast path is not good. Keep in mind that this >> is meant to handle a store followed by a load to another location >> scenario. We need to honor the #StoreLoad relationship for this type of >> setup for these types of algorithms. For instance, hazard pointers >> require a #StoreLoad, however there is a way to eliminate them using >> some special magic wrt RCU... >> >> My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard >> pointers. Now, keep in mind that these are very "specialized" algorithms >> that try to make certain workloads MUCH faster and way more efficient. >> They work for that. >> >> Also, keep in mind that a normal mutex does not require #StoreLoad. Only >> acquire and release: >> >> acquire = #LoadStore | #LoadLoad >> release = #LoadStore | #StoreStore >> >> In SPARC parlance. For instance, an atomic store on x86 automatically >> implies release. Btw, have you ever worked with SPARC in RMO mode? Its >> fun because its so weak. >> > > We discussed it already. I don't think that SPARCv9 RMO hardware > ever existed and you failed to convince me otherwise. Iirc, SPARC64 V9 can put into RMO mode. > > As to weakness, I don't think that by specification it is weaker than IPF, > may be not even weaker than POWER. Certainly stronger than Alpha. > But it does not matter since it does not exist. > >> I still need to find that old paper called QPI, if I remember correctly. >> It should still be out there. I will try to find it sometime today. >> >> It think is was from Dice wrt a Java VM. David Dice? Damn I cannot >> remember it right now. Sorry. ;^o >> >> >> [...]
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-26 14:07 -0700 |
| Message-ID | <uevh6q$2m8qq$2@dont-email.me> |
| In reply to | #92164 |
On 9/26/2023 1:58 PM, Michael S wrote: > On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote: >> On 9/26/2023 9:05 AM, Michael S wrote: >>> On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote: >>>> On 9/24/2023 10:04 AM, Kaz Kylheku wrote: >>>>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote: >>>>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: >>>>>> >>>>>>> A possible design is that each *thread* has a wait semaphore. >>>>>> >>>>>> You'd have to register the binary semaphore and register as a waiter in >>>>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't >>>>>> atomically update the link pointers of the other nodes at the same >>>>>> time you update the roots link pointers. And you would have the deallo- >>>>>> cation poblem, i.e. the memory of your object may never be deallocated. >>>>> >>>>> Now you're just throwing together words you don't understand. >>>>> >>>>>> Show me your implementation ! >>>>> >>>>> E.g. old LinuxThreads in glibc, circa 2000: >>>>> >>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe >>>>> >>>>> The low level __pthread_lock and __pthread_unlock functions maintain a >>>>> queue, using a single-word atomic CAS. >>>>> >>>>> There are suspend() and resume() functions for the waiting; >>>>> they are elsewhere. >>>>> >>>>> If you look in restart.h you can see that those operations are defined >>>>> in two different ways, both of which use signals (not a semaphore per >>>>> thread). A suspending thread waits for the arrival of a signal, >>>>> resume is done by sending a signal. That's kind of semaphore-like; >>>>> and POSIX real-time signals can even queue up, like a counting sem. >>>>> >>>>>> It's ridiculous because mutex are a cheap resource. And if such imple- >>>>>> mentation would be possible the standard shouldn't mandate it since >>>>>> not every platform has a DCAS. >>>>> >>>>> Things can be done in ways you havn't thought about. >>>>> >>>>> Atomic operations aren't required to achieve mutual exclusion among >>>>> processors that share memory. >>>>> >>>>> As someone continually insisting on having expertise in concurrency, >>>>> you must be familiar with the research work of Leslie Lamport? >>>> >>>> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a >>>> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit >>>> membar on the x86. MFENCE, or XCHG which has the lock prefix >>>> automatically asserted. Humm... There is a way to get around that >>>> bastard #StoreLoad membar... It uses an async sync setup. The funny >>>> thing is that Windows has a API that can be used to actually implement >>>> it! Try to think of a so called, remote memory barrier, in a sense: >>>> >>>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers >>>> >>>> There is a way to use this to get an async mutex that is kind of sort of >>>> akin to a read write mutex. Basically, the mutex is broken down into two >>>> parts. One that represents accesses that _very_ frequently called upon. >>>> The other one is used rather rarely. This is the async nature that can >>>> be exploited in rather interesting ways. I implemented some in the past >>>> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used >>>> to implement other rather exotic sync schemes. They have very excellent >>>> performance for certain workloads. Actually, there is a way to use it to >>>> get a RCU in userspace and/or hazard pointers without any explicit >>>> #StoreLoad membars. >>>> >>>> >>> >>> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude >>> slower than #StoreLoad membar. I could be wrong, of course, the function >>> is close to undocumented. >> FlushProcessWriteBuffers() can be used to gain a quiescent state wrt >> memory visibility for some exotic async algorithms, it is called in >> certain places and is RARE. However, on the other hand, having to use a >> #StoreLoad membar on the fast path is not good. Keep in mind that this >> is meant to handle a store followed by a load to another location >> scenario. We need to honor the #StoreLoad relationship for this type of >> setup for these types of algorithms. For instance, hazard pointers >> require a #StoreLoad, however there is a way to eliminate them using >> some special magic wrt RCU... >> >> My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard >> pointers. Now, keep in mind that these are very "specialized" algorithms >> that try to make certain workloads MUCH faster and way more efficient. >> They work for that. >> >> Also, keep in mind that a normal mutex does not require #StoreLoad. Only >> acquire and release: >> >> acquire = #LoadStore | #LoadLoad >> release = #LoadStore | #StoreStore >> >> In SPARC parlance. For instance, an atomic store on x86 automatically >> implies release. Btw, have you ever worked with SPARC in RMO mode? Its >> fun because its so weak. >> > > We discussed it already. I don't think that SPARCv9 RMO hardware > ever existed and you failed to convince me otherwise. Have you ever used SPARC before? Solaris? > > As to weakness, I don't think that by specification it is weaker than IPF, > may be not even weaker than POWER. Certainly stronger than Alpha. > But it does not matter since it does not exist. > >> I still need to find that old paper called QPI, if I remember correctly. >> It should still be out there. I will try to find it sometime today. >> >> It think is was from Dice wrt a Java VM. David Dice? Damn I cannot >> remember it right now. Sorry. ;^o >> >> >> [...]
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-26 14:11 -0700 |
| Message-ID | <uevhe1$2m8qq$3@dont-email.me> |
| In reply to | #92164 |
On 9/26/2023 1:58 PM, Michael S wrote: > On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote: >> On 9/26/2023 9:05 AM, Michael S wrote: >>> On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote: >>>> On 9/24/2023 10:04 AM, Kaz Kylheku wrote: >>>>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote: >>>>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: >>>>>> >>>>>>> A possible design is that each *thread* has a wait semaphore. >>>>>> >>>>>> You'd have to register the binary semaphore and register as a waiter in >>>>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't >>>>>> atomically update the link pointers of the other nodes at the same >>>>>> time you update the roots link pointers. And you would have the deallo- >>>>>> cation poblem, i.e. the memory of your object may never be deallocated. >>>>> >>>>> Now you're just throwing together words you don't understand. >>>>> >>>>>> Show me your implementation ! >>>>> >>>>> E.g. old LinuxThreads in glibc, circa 2000: >>>>> >>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe >>>>> >>>>> The low level __pthread_lock and __pthread_unlock functions maintain a >>>>> queue, using a single-word atomic CAS. >>>>> >>>>> There are suspend() and resume() functions for the waiting; >>>>> they are elsewhere. >>>>> >>>>> If you look in restart.h you can see that those operations are defined >>>>> in two different ways, both of which use signals (not a semaphore per >>>>> thread). A suspending thread waits for the arrival of a signal, >>>>> resume is done by sending a signal. That's kind of semaphore-like; >>>>> and POSIX real-time signals can even queue up, like a counting sem. >>>>> >>>>>> It's ridiculous because mutex are a cheap resource. And if such imple- >>>>>> mentation would be possible the standard shouldn't mandate it since >>>>>> not every platform has a DCAS. >>>>> >>>>> Things can be done in ways you havn't thought about. >>>>> >>>>> Atomic operations aren't required to achieve mutual exclusion among >>>>> processors that share memory. >>>>> >>>>> As someone continually insisting on having expertise in concurrency, >>>>> you must be familiar with the research work of Leslie Lamport? >>>> >>>> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a >>>> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit >>>> membar on the x86. MFENCE, or XCHG which has the lock prefix >>>> automatically asserted. Humm... There is a way to get around that >>>> bastard #StoreLoad membar... It uses an async sync setup. The funny >>>> thing is that Windows has a API that can be used to actually implement >>>> it! Try to think of a so called, remote memory barrier, in a sense: >>>> >>>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers >>>> >>>> There is a way to use this to get an async mutex that is kind of sort of >>>> akin to a read write mutex. Basically, the mutex is broken down into two >>>> parts. One that represents accesses that _very_ frequently called upon. >>>> The other one is used rather rarely. This is the async nature that can >>>> be exploited in rather interesting ways. I implemented some in the past >>>> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used >>>> to implement other rather exotic sync schemes. They have very excellent >>>> performance for certain workloads. Actually, there is a way to use it to >>>> get a RCU in userspace and/or hazard pointers without any explicit >>>> #StoreLoad membars. >>>> >>>> >>> >>> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude >>> slower than #StoreLoad membar. I could be wrong, of course, the function >>> is close to undocumented. >> FlushProcessWriteBuffers() can be used to gain a quiescent state wrt >> memory visibility for some exotic async algorithms, it is called in >> certain places and is RARE. However, on the other hand, having to use a >> #StoreLoad membar on the fast path is not good. Keep in mind that this >> is meant to handle a store followed by a load to another location >> scenario. We need to honor the #StoreLoad relationship for this type of >> setup for these types of algorithms. For instance, hazard pointers >> require a #StoreLoad, however there is a way to eliminate them using >> some special magic wrt RCU... >> >> My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard >> pointers. Now, keep in mind that these are very "specialized" algorithms >> that try to make certain workloads MUCH faster and way more efficient. >> They work for that. >> >> Also, keep in mind that a normal mutex does not require #StoreLoad. Only >> acquire and release: >> >> acquire = #LoadStore | #LoadLoad >> release = #LoadStore | #StoreStore >> >> In SPARC parlance. For instance, an atomic store on x86 automatically >> implies release. Btw, have you ever worked with SPARC in RMO mode? Its >> fun because its so weak. >> > > We discussed it already. I don't think that SPARCv9 RMO hardware > ever existed and you failed to convince me otherwise. [...] heck, have you ever had to use a DEC Alpha that was so weak it did not even honor data dependent loads? This is interesting wrt RCU... ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-26 14:17 -0700 |
| Message-ID | <uevhpp$2m8qq$4@dont-email.me> |
| In reply to | #92164 |
On 9/26/2023 1:58 PM, Michael S wrote: > On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote: >> On 9/26/2023 9:05 AM, Michael S wrote: >>> On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote: >>>> On 9/24/2023 10:04 AM, Kaz Kylheku wrote: >>>>> On 2023-09-24, Bonita Montero <Bonita....@gmail.com> wrote: >>>>>> Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: >>>>>> >>>>>>> A possible design is that each *thread* has a wait semaphore. >>>>>> >>>>>> You'd have to register the binary semaphore and register as a waiter in >>>>>> one atomic step. You could do that with a DCAS'd ring, but you coudn't >>>>>> atomically update the link pointers of the other nodes at the same >>>>>> time you update the roots link pointers. And you would have the deallo- >>>>>> cation poblem, i.e. the memory of your object may never be deallocated. >>>>> >>>>> Now you're just throwing together words you don't understand. >>>>> >>>>>> Show me your implementation ! >>>>> >>>>> E.g. old LinuxThreads in glibc, circa 2000: >>>>> >>>>> https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe >>>>> >>>>> The low level __pthread_lock and __pthread_unlock functions maintain a >>>>> queue, using a single-word atomic CAS. >>>>> >>>>> There are suspend() and resume() functions for the waiting; >>>>> they are elsewhere. >>>>> >>>>> If you look in restart.h you can see that those operations are defined >>>>> in two different ways, both of which use signals (not a semaphore per >>>>> thread). A suspending thread waits for the arrival of a signal, >>>>> resume is done by sending a signal. That's kind of semaphore-like; >>>>> and POSIX real-time signals can even queue up, like a counting sem. >>>>> >>>>>> It's ridiculous because mutex are a cheap resource. And if such imple- >>>>>> mentation would be possible the standard shouldn't mandate it since >>>>>> not every platform has a DCAS. >>>>> >>>>> Things can be done in ways you havn't thought about. >>>>> >>>>> Atomic operations aren't required to achieve mutual exclusion among >>>>> processors that share memory. >>>>> >>>>> As someone continually insisting on having expertise in concurrency, >>>>> you must be familiar with the research work of Leslie Lamport? >>>> >>>> Iirc, that uses atomic loads, stores and membars. Iirc, it requires a >>>> #StoreLoad barrier on the SPARC. Iirc, it even requires an explicit >>>> membar on the x86. MFENCE, or XCHG which has the lock prefix >>>> automatically asserted. Humm... There is a way to get around that >>>> bastard #StoreLoad membar... It uses an async sync setup. The funny >>>> thing is that Windows has a API that can be used to actually implement >>>> it! Try to think of a so called, remote memory barrier, in a sense: >>>> >>>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers >>>> >>>> There is a way to use this to get an async mutex that is kind of sort of >>>> akin to a read write mutex. Basically, the mutex is broken down into two >>>> parts. One that represents accesses that _very_ frequently called upon. >>>> The other one is used rather rarely. This is the async nature that can >>>> be exploited in rather interesting ways. I implemented some in the past >>>> with Dmitry Vyukov. Also, this FlushProcessWriteBuffers API can be used >>>> to implement other rather exotic sync schemes. They have very excellent >>>> performance for certain workloads. Actually, there is a way to use it to >>>> get a RCU in userspace and/or hazard pointers without any explicit >>>> #StoreLoad membars. >>>> >>>> >>> >>> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude >>> slower than #StoreLoad membar. I could be wrong, of course, the function >>> is close to undocumented. >> FlushProcessWriteBuffers() can be used to gain a quiescent state wrt >> memory visibility for some exotic async algorithms, it is called in >> certain places and is RARE. However, on the other hand, having to use a >> #StoreLoad membar on the fast path is not good. Keep in mind that this >> is meant to handle a store followed by a load to another location >> scenario. We need to honor the #StoreLoad relationship for this type of >> setup for these types of algorithms. For instance, hazard pointers >> require a #StoreLoad, however there is a way to eliminate them using >> some special magic wrt RCU... >> >> My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard >> pointers. Now, keep in mind that these are very "specialized" algorithms >> that try to make certain workloads MUCH faster and way more efficient. >> They work for that. >> >> Also, keep in mind that a normal mutex does not require #StoreLoad. Only >> acquire and release: >> >> acquire = #LoadStore | #LoadLoad >> release = #LoadStore | #StoreStore >> >> In SPARC parlance. For instance, an atomic store on x86 automatically >> implies release. Btw, have you ever worked with SPARC in RMO mode? Its >> fun because its so weak. >> > > We discussed it already. I don't think that SPARCv9 RMO hardware > ever existed and you failed to convince me otherwise. > > As to weakness, I don't think that by specification it is weaker than IPF, > may be not even weaker than POWER. Certainly stronger than Alpha. The damn DEC Alpha did not even honor data-dependent loads, that is very weak. It's so weak it has to use membars to implement RCU. Sparc in RMO mode requires explicit MEMBAR for acquire and release. IN TSO mode it had implicit acquire and release wrt loads and stores much like x86.
[toc] | [prev] | [next] | [standalone]
| From | Michael Fisher <michaelsfishers61@gmail.com> |
|---|---|
| Date | 2023-09-26 14:40 -0700 |
| Message-ID | <12308a3d-9cc3-45b0-b556-78b290a7cdcfn@googlegroups.com> |
| In reply to | #92168 |
Buy your driver's license,Passport, Visa, EITLS exams, Fake bank notes whatsapp: +1(541)782-8482 we supply perfectly reproduced counterfeit money with holograms and all security features available. Indistinguishable to the eye and to touch.contact today whatsapp : +1(541)782-8482 Email: Cliffbudman237@gmail.com https://procounterfeitshop.company.com/ Why would you buy from us? Our banknotes contain the following security features that make it to be genius and we have the best grade counterfeit in the world both Euro and Dollar and any bills of your choice you want. Security features of our bank notes are AAA grade with the following quality : Intaglio printing Watermarks Security thread See-through register Special foil/special foil elements Iridescent stripe / shifting colors. -Holograms and Holographic Strips -Micro-Lettering -Metallic Ink and Thread -Watermarks -IR Detection -Ultra-violet features -See through Features -Different serial numberwe offer both national and international deliveries. All of our deliveries are safe, fast and discreet. All customer delivery information is eliminated after delivery to ensure a fair deal . We supply only original high-quality BANKNOTES to all countries worldwide. We print and sell perfect Grade A BANKNOTES of over 52 currencies. Our money is perfectly reproduced with all security features available and we assure you everything is safe and indistinguishable to the human eye and touch (REAL MONEY LOOK AND FEEL). EUR - Euro USD - US Dollar GBP - British Pound AUD - Australian Dollar CAD - Canadian and many more Delivery usually takes 2-5 days -Free shipping -THE bills/notes bypass everything, counterfeit pens and machines. -I have the best HOLOGRAMS AND DUPLICATING MACHINES -UV: YES -All security features available contact today whatsapp : whatsapp : +1(541)782-8482 Email: Cliffbudman237@gmail.com https://procounterfeitshop.company.com/ WHERE CAN I USE THESE BANKNOTE? MC DONALD'S , SHOPS , RESTAURANTS , SUPERMARKETS , PETROL SHOPS , GAME HALL , ATM, BANKS,SHOPPING MALLS , GAME AND ATTRACTION PARKS , ELECTRONIC SHOPS , TAXI , METRO AND TRAIN STATION , USED TO PAY BUS AND ANY TRANSPORTATION Tags: counterfeit cash, counterfeiting High Quality Undetectable Counterfeit Banknotes For Sale HIGH QUALITY UNDETECTABLE COUNTERFEIT BANKNOTES FOR SALE BUY SUPER HIGH QUALITY FAKE MONEY ONLINE GBP, DOLLAR, EUROS BUY 100% UNDETECTABLE COUNTERFEIT MONEY £,$,€ BEST COUNTERFEIT MONEY ONLINE, DOLLARS, GBP, EURO NOTES AVAILABLE BUY TOP GRADE COUNTERFEIT MONEY ONLINE, DOLLARS, GBP, EURO NOTES AVAILABLE. TOP QUALITY COUNTERFEIT MONEY FOR SALE. DOLLAR, POUNDS, EUROS AND OTHER CURRENCIES AVAILABLE Counterfeit money for sale money, banknotes, fake money, prop money, EUROS,DOLLARS AND POUNDS AND NOVELTY DOCUMENTS LIKE PASSPORTS,ID CARDS,GREEN CARDS AND DRIVERS LICENSE counterfeit money for sale, buy fake money online, fake dollars, fake pounds, fake euro, buy money online, fake money for sale. Buy Fake Dollars, Buy Fake British Pounds, Buy Fake Euro, Money, where can i buy counterfeit money?. BUY QUALITY COUNTERFEIT MONEY WHATSAPP ME AT +1(541)782-8482 EUROS,DOLLARS AND POUNDS .AND S.S.D CHEMICALS.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-24 11:34 -0700 |
| Message-ID | <uepvfk$1ff81$1@dont-email.me> |
| In reply to | #92044 |
On 9/24/2023 1:08 AM, Bonita Montero wrote: > Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: > >> A possible design is that each *thread* has a wait semaphore. > > You'd have to register the binary semaphore and register as a waiter in > one atomic step. You could do that with a DCAS'd ring, but you coudn't > atomically update the link pointers of the other nodes at the same > time you update the roots link pointers. And you would have the deallo- > cation poblem, i.e. the memory of your object may never be deallocated. > Show me your implementation ! > It's ridiculous because mutex are a cheap resource. And if such imple- > mentation would be possible the standard shouldn't mandate it since > not every platform has a DCAS. > Pardon my French, but that is a rather horrible idea, for several reasons...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-22 22:22 +0000 |
| Message-ID | <IsoPM.20139$wO91.15127@fx39.iad> |
| In reply to | #91999 |
Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 22.09.2023 um 19:56 schrieb Scott Lurndal:
>
>> Why on earth would the run-time/dynamic loader use a C++ mutex
>> instead of an implementation-defined primitive (e.g. pthread_once,
>> pthread_mutex_t) which are easily statically initalized?
>
>pthread_mutex_init() can fail
That is beside the point. The mutex can be statically initialized
and the pthread_mutex_init call is unnecessary. You've been informed
of this point at least a half dozen times in this thread alone.
SYNOPSIS
#include <pthread.h>
int pthread_mutex_destroy(pthread_mutex_t *mutex);
int pthread_mutex_init(pthread_mutex_t *restrict mutex,
const pthread_mutexattr_t *restrict attr);
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-22 17:44 -0700 |
| Message-ID | <uelce5$g184$1@dont-email.me> |
| In reply to | #92002 |
On 9/22/2023 3:22 PM, Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 22.09.2023 um 19:56 schrieb Scott Lurndal: >> >>> Why on earth would the run-time/dynamic loader use a C++ mutex >>> instead of an implementation-defined primitive (e.g. pthread_once, >>> pthread_mutex_t) which are easily statically initalized? >> >> pthread_mutex_init() can fail > > That is beside the point. The mutex can be statically initialized > and the pthread_mutex_init call is unnecessary. You've been informed > of this point at least a half dozen times in this thread alone. > > SYNOPSIS > #include <pthread.h> > > int pthread_mutex_destroy(pthread_mutex_t *mutex); > int pthread_mutex_init(pthread_mutex_t *restrict mutex, > const pthread_mutexattr_t *restrict attr); > pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; > Bonita sure seems to be very set in its ways. Since this is not something it knows about, it can tend to get fairly angry and lash out with verbal assaults.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-23 06:42 +0200 |
| Message-ID | <uelqb1$lo9j$3@dont-email.me> |
| In reply to | #92002 |
Am 23.09.2023 um 00:22 schrieb Scott Lurndal: > That is beside the point. The mutex can be statically initialized > ... This depends on the program which uses the mutex.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-23 15:00 +0000 |
| Message-ID | <24DPM.126389$Hih7.28245@fx11.iad> |
| In reply to | #92016 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 23.09.2023 um 00:22 schrieb Scott Lurndal: > >> That is beside the point. The mutex can be statically initialized >> ... > >This depends on the program which uses the mutex. Nice topic shift. Not. We're talking specifically about the implementation mechanism used to serialize static initialization of a function-scope static object.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-23 17:23 +0200 |
| Message-ID | <uemvt2$rcgo$1@dont-email.me> |
| In reply to | #92027 |
Am 23.09.2023 um 17:00 schrieb Scott Lurndal: > We're talking specifically about the implementation mechanism > used to serialize static initialization of a function-scope > static object. I've noticed that a Pthread mutex can be statically initialized and Win32's CRITICAL_SECTION never fails on initialization either. But this mean that the semaphore for the slow path on contention has to be initialized delayed. So if there's contention the sychronization can still fail. And even if the semaphore creation doesn't fail the synchronization on it may fail, depending on the implementation inside the kernel, f.e. if there's no memory for an additional entry in the wait-queue on the semaphore. I think it's ridiculous to say "look at operating system X, it would never fail" since that's not the way the standard should be designed. As I've shown this may be true for the synchronization part only but for sure not for the creation of the binary semaphore. If std::mutex may fail on synchronization and implementations have to create the kernel part of the "mutexes" for static initialization on demand, static initialization should be definedto throw a system_error. The probability of this happening is very low, simply because the probability of contention at this point is usually low and creating a semaphore may fail under rare conditions, but what happens then needs to be clearly defined for me. std::mutex has defined means to handle that, static initialization not.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-23 20:05 -0700 |
| Message-ID | <ueo915$16kh3$2@dont-email.me> |
| In reply to | #92028 |
On 9/23/2023 8:23 AM, Bonita Montero wrote: > Am 23.09.2023 um 17:00 schrieb Scott Lurndal: > >> We're talking specifically about the implementation mechanism >> used to serialize static initialization of a function-scope >> static object. > > I've noticed that a Pthread mutex can be statically initialized and > Win32's CRITICAL_SECTION never fails on initialization either. But > this mean that the semaphore for the slow path on contention has to > be initialized delayed. So if there's contention the sychronization > can still fail. > And even if the semaphore creation doesn't fail the synchronization > on it may fail, depending on the implementation inside the kernel, > f.e. if there's no memory for an additional entry in the wait-queue > on the semaphore. > I think it's ridiculous to say "look at operating system X, it would > never fail" since that's not the way the standard should be designed. > As I've shown this may be true for the synchronization part only but > for sure not for the creation of the binary semaphore. > If std::mutex may fail on synchronization and implementations have > to create the kernel part of the "mutexes" for static initialization > on demand, static initialization should be definedto throw a > system_error. > The probability of this happening is very low, simply because the > probability of contention at this point is usually low and creating > a semaphore may fail under rare conditions, but what happens then > needs to be clearly defined for me. std::mutex has defined means > to handle that, static initialization not. > > Why do you think that static initialization must use a std::mutex anyway? Why do you think that std::mutex must use some delayed kernel resource initialization? Strange.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-09-24 10:09 +0200 |
| Message-ID | <ueoqra$19436$2@dont-email.me> |
| In reply to | #92041 |
Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson: > Why do you think that static initialization must use a std::mutex > anyway? ... Call it std::mutex or whatever. It is mandated that contenders are sleeping - that's not possible without sth. else than a mutex.
[toc] | [prev] | [next] | [standalone]
Page 27 of 34 — ← Prev page 1 … 25 26 [27] 28 29 … 34 Next page →
Back to top | Article view | comp.lang.c++
csiph-web