Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #81355 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2021-09-20 22:43 +0200 |
| Last post | 2021-10-28 20:29 -0700 |
| Articles | 20 on this page of 190 — 11 participants |
Back to article view | Back to comp.lang.c++
Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-20 22:43 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-23 10:38 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-23 20:29 +0200
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-23 20:30 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-24 18:48 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-24 18:56 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 07:24 +0200
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 12:28 +0000
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 15:57 +0200
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 13:59 +0000
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 16:09 +0200
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 17:13 +0000
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 19:15 +0200
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 17:22 +0000
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-26 05:46 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-04 01:19 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-04 13:50 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-04 10:08 -0700
Re: Tricky ... Öö Tiib <ootiib@hot.ee> - 2021-10-04 08:50 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-04 10:07 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-25 13:34 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-26 05:48 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-27 22:46 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 08:34 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-28 00:05 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 12:06 +0200
Re: Tricky ... David Brown <david.brown@hesbynett.no> - 2021-09-28 16:05 +0200
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 18:46 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-28 14:02 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-28 14:42 -0700
Re: Tricky ... red floyd <no.spam.here@its.invalid> - 2021-09-28 17:05 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-28 19:28 -0700
Re: Tricky ... David Brown <david.brown@hesbynett.no> - 2021-09-29 08:35 +0200
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-29 12:42 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-29 12:04 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-29 12:41 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-29 12:05 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-30 03:33 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-29 18:43 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-29 19:47 -0700
Re: Tricky ... David Brown <david.brown@hesbynett.no> - 2021-09-30 09:10 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 18:00 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 18:01 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 02:32 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-29 12:05 -0700
Re: Tricky ... HorseyWorsey@the_stables.com - 2021-09-30 09:35 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 13:19 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-27 00:18 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-27 14:44 +0200
Re: Tricky ... red floyd <no.spam.here@its.invalid> - 2021-09-27 10:54 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-27 14:10 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-27 14:06 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-27 16:09 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 06:57 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-27 22:28 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 08:33 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-28 00:03 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 12:05 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-29 21:57 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-30 08:16 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-30 01:19 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-30 12:39 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-30 13:20 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 03:32 +0200
Re: Tricky ... Öö Tiib <ootiib@hot.ee> - 2021-10-01 04:43 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-01 14:59 +0200
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-01 13:10 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 13:04 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-01 20:53 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 14:24 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-01 22:13 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 17:14 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 17:16 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 01:44 +0000
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 02:14 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 19:33 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 06:39 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 22:12 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 07:35 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 22:49 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 08:00 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 23:12 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 08:38 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 23:39 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 08:46 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 23:50 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 08:52 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 00:01 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 09:12 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 00:26 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 11:16 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 03:03 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 13:06 +0200
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 13:07 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-06 18:22 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-09 09:38 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-09 12:29 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-09 21:59 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-09 13:13 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-10 06:42 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-09 22:04 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 13:20 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 06:40 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 22:12 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 22:14 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 07:36 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 22:55 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 08:00 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 23:08 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 08:38 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 23:41 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 23:44 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 08:47 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 23:51 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 08:53 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 00:04 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 09:13 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 00:20 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 09:30 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 00:32 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 10:27 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-04 11:31 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-05 07:13 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-06 12:22 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:36 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-07 00:31 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 12:15 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-07 12:21 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-07 20:14 +0000
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-08 07:52 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-08 12:56 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 00:24 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 09:31 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 00:32 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 10:27 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 01:36 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-02 10:57 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-06 17:19 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-07 02:17 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-06 19:38 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-07 02:45 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-06 20:01 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-07 03:24 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-08 13:13 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 08:37 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-07 01:15 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-07 12:16 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-07 12:26 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-07 20:16 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-07 14:27 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-07 23:27 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-08 15:24 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-08 07:53 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-08 12:53 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-01 13:08 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 00:31 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-02 00:52 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 06:55 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-27 22:27 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-27 22:49 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 02:31 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-28 20:14 -0700
Re: Tricky ... Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-28 08:33 +0200
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-28 00:06 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-29 12:09 -0700
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-09-30 13:00 -0700
Re: Tricky ... RadicalRabbit@theburrow.co.uk - 2021-10-01 09:17 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 13:11 -0700
Re: Tricky ... RadicalRabbit@theburrow.co.uk - 2021-10-03 08:25 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-03 13:21 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 21:06 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-03 14:33 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 04:42 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-06 18:11 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-07 02:20 +0000
Re: Tricky ... Ian Collins <ian-news@hotmail.com> - 2021-10-07 22:26 +1300
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-08 14:07 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-01 13:07 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-01 13:08 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-01 20:54 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-03 13:33 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 21:07 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-03 14:51 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 04:44 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-08 13:05 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-09 07:29 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-09 19:55 -0700
Re: Tricky ... Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-11 05:21 +0000
Re: Tricky ... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-28 13:49 -0700
Re: Tricky ... "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-10-28 20:29 -0700
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-30 09:10 +0200 |
| Message-ID | <sj3nth$9f$1@dont-email.me> |
| In reply to | #81683 |
On 30/09/2021 03:33, Bonita Montero wrote: > Am 29.09.2021 um 21:05 schrieb Chris M. Thomasson: >> On 9/29/2021 3:41 AM, Bonita Montero wrote: >>> Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson: >>> >>>> Yeah. Damn. She does not seem to know a whole lot about memory >>>> barriers, >>> >>> I use them a lot and correctly. >>> >> >> A wait on a semaphore does not need release semantics. ... > > It needs because I could have modiefied data before releasing the > lock I'm waiting for just at the same time. > If you release a lock, you need release semantics. If you acquire a lock, you need acquire semantics. There is a lot of fiddly stuff in getting memory barriers and synchronisation right - and a lot of /really/ tough stuff in getting it right and optimally efficient on big processors. But "acquire" and "release" semantics are helpfully named!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 18:00 -0700 |
| Message-ID | <sj8avp$q0u$1@gioia.aioe.org> |
| In reply to | #81689 |
On 9/30/2021 12:10 AM, David Brown wrote: > On 30/09/2021 03:33, Bonita Montero wrote: >> Am 29.09.2021 um 21:05 schrieb Chris M. Thomasson: >>> On 9/29/2021 3:41 AM, Bonita Montero wrote: >>>> Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson: >>>> >>>>> Yeah. Damn. She does not seem to know a whole lot about memory >>>>> barriers, >>>> >>>> I use them a lot and correctly. >>>> >>> >>> A wait on a semaphore does not need release semantics. ... >> >> It needs because I could have modiefied data before releasing the >> lock I'm waiting for just at the same time. >> > > If you release a lock, you need release semantics. If you acquire a > lock, you need acquire semantics. > > There is a lot of fiddly stuff in getting memory barriers and > synchronisation right - and a lot of /really/ tough stuff in getting it > right and optimally efficient on big processors. But "acquire" and > "release" semantics are helpfully named! > They are named nicely. Back on the SPARC acquire is: MEMBAR #LoadStore | #LoadLoad Release is: MEMBAR #LoadStore | #StoreStore Ahhh, then we have hardcore: #StoreLoad. SMR required this on the SPARC.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 18:01 -0700 |
| Message-ID | <sj8b1v$q0u$2@gioia.aioe.org> |
| In reply to | #81728 |
On 10/1/2021 6:00 PM, Chris M. Thomasson wrote: > On 9/30/2021 12:10 AM, David Brown wrote: >> On 30/09/2021 03:33, Bonita Montero wrote: >>> Am 29.09.2021 um 21:05 schrieb Chris M. Thomasson: >>>> On 9/29/2021 3:41 AM, Bonita Montero wrote: >>>>> Am 28.09.2021 um 23:42 schrieb Chris M. Thomasson: >>>>> >>>>>> Yeah. Damn. She does not seem to know a whole lot about memory >>>>>> barriers, >>>>> >>>>> I use them a lot and correctly. >>>>> >>>> >>>> A wait on a semaphore does not need release semantics. ... >>> >>> It needs because I could have modiefied data before releasing the >>> lock I'm waiting for just at the same time. >>> >> >> If you release a lock, you need release semantics. If you acquire a >> lock, you need acquire semantics. >> >> There is a lot of fiddly stuff in getting memory barriers and >> synchronisation right - and a lot of /really/ tough stuff in getting it >> right and optimally efficient on big processors. But "acquire" and >> "release" semantics are helpfully named! >> > > They are named nicely. Back on the SPARC acquire is: > > MEMBAR #LoadStore | #LoadLoad > > Release is: > > MEMBAR #LoadStore | #StoreStore > > Ahhh, then we have hardcore: #StoreLoad. SMR required this on the SPARC. Heck, it even required it on the x86! LOCK'ed atomic or MFENCE.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-29 02:32 +0000 |
| Message-ID | <8fQ4J.17932$d82.14912@fx21.iad> |
| In reply to | #81653 |
On 2021-09-28, David Brown <david.brown@hesbynett.no> wrote: > On 28/09/2021 12:06, Bonita Montero wrote: >> Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson: >>> On 9/27/2021 11:34 PM, Bonita Montero wrote: > >>>> If the system hasn't any resources to satisfy a simple WaitForSingle... >>>> spinning is quite o.k.. >>>> >>> >>> spinning indeed. However, you have no backoff. You are spinning full >>> speed! >>> while( !SetEvent( (HANDLE)m_xhEvtVisit ) ); >>> Oh shit. When shit hits the fan, so does this! Try to not bleed the >>> system when its in dire straights? >> >> That doesnt't matter under such conditions. >> Am I talking to a complete moron here ? > > Chris, why do you keep trying to communicate with Bonita? She is > clearly so convinced of her own superiority to everyone else that it is > pointless. She does not post code for people to check, she posts it > because she thinks she is showing off and impressing people. This kind > of code is difficult to get right, and any capable developer is going to > want to discuss it with people to check the details. Since Bonita > responds with nothing but insults and arrogance, I think it is safe to > assume her code is flawed and leave her with it. She is clever, but newb. Forgive her for that. -- 7-77-777 Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-29 12:05 -0700 |
| Message-ID | <sj2ddk$flr$3@gioia.aioe.org> |
| In reply to | #81664 |
On 9/28/2021 7:32 PM, Branimir Maksimovic wrote: > On 2021-09-28, David Brown <david.brown@hesbynett.no> wrote: >> On 28/09/2021 12:06, Bonita Montero wrote: >>> Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson: >>>> On 9/27/2021 11:34 PM, Bonita Montero wrote: >> >>>>> If the system hasn't any resources to satisfy a simple WaitForSingle... >>>>> spinning is quite o.k.. >>>>> >>>> >>>> spinning indeed. However, you have no backoff. You are spinning full >>>> speed! >>>> while( !SetEvent( (HANDLE)m_xhEvtVisit ) ); >>>> Oh shit. When shit hits the fan, so does this! Try to not bleed the >>>> system when its in dire straights? >>> >>> That doesnt't matter under such conditions. >>> Am I talking to a complete moron here ? >> >> Chris, why do you keep trying to communicate with Bonita? She is >> clearly so convinced of her own superiority to everyone else that it is >> pointless. She does not post code for people to check, she posts it >> because she thinks she is showing off and impressing people. This kind >> of code is difficult to get right, and any capable developer is going to >> want to discuss it with people to check the details. Since Bonita >> responds with nothing but insults and arrogance, I think it is safe to >> assume her code is flawed and leave her with it. > She is clever, but newb. Forgive her for that. > She is clever.
[toc] | [prev] | [next] | [standalone]
| From | HorseyWorsey@the_stables.com |
|---|---|
| Date | 2021-09-30 09:35 +0000 |
| Message-ID | <sj40d1$1ec9$1@gioia.aioe.org> |
| In reply to | #81681 |
On Wed, 29 Sep 2021 12:05:24 -0700 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >On 9/28/2021 7:32 PM, Branimir Maksimovic wrote: >> On 2021-09-28, David Brown <david.brown@hesbynett.no> wrote: >>> On 28/09/2021 12:06, Bonita Montero wrote: >>>> Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson: >>>>> On 9/27/2021 11:34 PM, Bonita Montero wrote: >>> >>>>>> If the system hasn't any resources to satisfy a simple WaitForSingle... >>>>>> spinning is quite o.k.. >>>>>> >>>>> >>>>> spinning indeed. However, you have no backoff. You are spinning full >>>>> speed! >>>>> while( !SetEvent( (HANDLE)m_xhEvtVisit ) ); >>>>> Oh shit. When shit hits the fan, so does this! Try to not bleed the >>>>> system when its in dire straights? >>>> >>>> That doesnt't matter under such conditions. >>>> Am I talking to a complete moron here ? >>> >>> Chris, why do you keep trying to communicate with Bonita? She is >>> clearly so convinced of her own superiority to everyone else that it is >>> pointless. She does not post code for people to check, she posts it >>> because she thinks she is showing off and impressing people. This kind >>> of code is difficult to get right, and any capable developer is going to >>> want to discuss it with people to check the details. Since Bonita >>> responds with nothing but insults and arrogance, I think it is safe to >>> assume her code is flawed and leave her with it. >> She is clever, but newb. Forgive her for that. >> > >She is clever. Clever in a small area. She seems to have limited knowledge of development and OS methodologies that arn't commonly used in Windows however.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 13:19 -0700 |
| Message-ID | <sj7qgi$1a9q$1@gioia.aioe.org> |
| In reply to | #81691 |
On 9/30/2021 2:35 AM, HorseyWorsey@the_stables.com wrote: > On Wed, 29 Sep 2021 12:05:24 -0700 > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >> On 9/28/2021 7:32 PM, Branimir Maksimovic wrote: >>> On 2021-09-28, David Brown <david.brown@hesbynett.no> wrote: >>>> On 28/09/2021 12:06, Bonita Montero wrote: >>>>> Am 28.09.2021 um 09:05 schrieb Chris M. Thomasson: >>>>>> On 9/27/2021 11:34 PM, Bonita Montero wrote: >>>> >>>>>>> If the system hasn't any resources to satisfy a simple WaitForSingle... >>>>>>> spinning is quite o.k.. >>>>>>> >>>>>> >>>>>> spinning indeed. However, you have no backoff. You are spinning full >>>>>> speed! >>>>>> while( !SetEvent( (HANDLE)m_xhEvtVisit ) ); >>>>>> Oh shit. When shit hits the fan, so does this! Try to not bleed the >>>>>> system when its in dire straights? >>>>> >>>>> That doesnt't matter under such conditions. >>>>> Am I talking to a complete moron here ? >>>> >>>> Chris, why do you keep trying to communicate with Bonita? She is >>>> clearly so convinced of her own superiority to everyone else that it is >>>> pointless. She does not post code for people to check, she posts it >>>> because she thinks she is showing off and impressing people. This kind >>>> of code is difficult to get right, and any capable developer is going to >>>> want to discuss it with people to check the details. Since Bonita >>>> responds with nothing but insults and arrogance, I think it is safe to >>>> assume her code is flawed and leave her with it. >>> She is clever, but newb. Forgive her for that. >>> >> >> She is clever. > > Clever in a small area. She seems to have limited knowledge of development > and OS methodologies that arn't commonly used in Windows however. > She seems to make absolute statements based on her rather narrow views. Iirc, she even said something akin to a mutex implementation must use compare-and-swap. I showed her how to do one using only exchange. Recently, in this thread she said a lock-free structure, say a lock-free stack, has to use spin-polling to wait for an empty state to become, non-empty. Well, she is wrong, yet again.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-27 00:18 -0700 |
| Message-ID | <sirr80$fqe$1@gioia.aioe.org> |
| In reply to | #81355 |
On 9/20/2021 1:43 PM, Bonita Montero wrote:
> In some code I've to check different sates for which an exception might
> be thrown. These states are all true or false so I combined them to a
> four bit pattern wich I used as an index to a table which stores the
> strings of the out_of_range exception to be trown or a nullptr if the
> state isn't associated with an out of range condition. This helps me
> to prevent some if-else-cascades and speeds up the code.
> So this is the complete function but i put two empty lines around the
> code I mentioned.
>
> void dual_monitor::wait( bool b )
> {
> uint64_t cmp = m_flagAndCounters.load( memory_order_relaxed ), chg;
> uint32_t visitors, aWaiters, bWaiters, waiters;
> assert(m_tid == thread_id::self());
> m_tid = thread_id();
> do
> {
> assert(isOwned( cmp ) && !m_recCount);
> visitors = getVisitors( cmp );
> aWaiters = getAWaiters( cmp );
> bWaiters = getAWaiters( cmp );
> assert(visitors >= aWaiters + bWaiters);
> waiters = !b ? aWaiters : bWaiters;
>
> static
> char const *const throwTable[] =
> {
> nullptr /* 0000 */, nullptr /* 0001 */, nullptr /* 0010 */,
> nullptr /* 0011 */, nullptr /* 0100 */, nullptr /* 0101 */,
> "monitor::wait() - number of visitors and a-waiters too
> large", // 0110
> "monitor::wait() - number of visitors and a-waiters too
> large", // 0111
> nullptr /* 1000 */, nullptr /* 1001 */, nullptr /* 1010 */,
> nullptr /* 1011 */, nullptr /* 1100 */,
> "monitor::wait() - number of visitors and b-waiters too
> large", // 1101
> nullptr, // 1110
> "monitor::wait() - number of visitors and b-waiters too
> large", // 1111
> };
> size_t maxVisitors = visitors == COUNTER_MASK,
> maxAWaiters = aWaiters == COUNTER_MASK,
> maxBWaiters = bWaiters == COUNTER_MASK;
> size_t throwIdx = (size_t)b << 3 | maxVisitors << 2 |
> maxAWaiters << 1 | maxBWaiters;
> if( throwTable[throwIdx] )
> {
> m_tid = thread_id::self();
> throw out_of_range( throwTable[throwIdx] );
> };
>
> if( visitors > waiters )
> // waiters < COUNTER_MASK because visitors > waiters
> // taking over visitor-counter from another thread
> chg = cmp + (!b ? WAITER_A_VALUE : WAITER_B_VALUE);
> else
> // visitors == aWaiters + bWaiters
> chg = (cmp & ~OWNER_MASK) + (!b ? WAITER_A_VALUE :
> WAITER_B_VALUE) + VISITOR_VALUE;
> } while( !m_flagAndCounters.compare_exchange_weak( cmp, chg,
> memory_order_release, memory_order_relaxed ) );
[...]
Humm... For some reason I feel the need for std::memory_order_acq_rel
here wrt the cas. Humm... I need to port your algorihtm over to a form
that Relacy can understand. Its been a while! I just got a strange
feeling. Waiting is usually, acquire semantics. Humm... Sorry, need to
examine it further, and port it over. Then run it in certain scenarios.
Relacy has the capability to crack it wide open if there are any issues.
I should have some time later on tomorrow. I am busy with my fractal
software right now:
https://fractalforums.org/gallery/1612-270921004032.jpeg
http://siggrapharts.ning.com/photo/alien-anatomy
lol. ;^)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-09-27 14:44 +0200 |
| Message-ID | <sisebf$j1h$1@dont-email.me> |
| In reply to | #81616 |
Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson:
> On 9/20/2021 1:43 PM, Bonita Montero wrote:
>> In some code I've to check different sates for which an exception might
>> be thrown. These states are all true or false so I combined them to a
>> four bit pattern wich I used as an index to a table which stores the
>> strings of the out_of_range exception to be trown or a nullptr if the
>> state isn't associated with an out of range condition. This helps me
>> to prevent some if-else-cascades and speeds up the code.
>> So this is the complete function but i put two empty lines around the
>> code I mentioned.
>>
>> void dual_monitor::wait( bool b )
>> {
>> uint64_t cmp = m_flagAndCounters.load( memory_order_relaxed ), chg;
>> uint32_t visitors, aWaiters, bWaiters, waiters;
>> assert(m_tid == thread_id::self());
>> m_tid = thread_id();
>> do
>> {
>> assert(isOwned( cmp ) && !m_recCount);
>> visitors = getVisitors( cmp );
>> aWaiters = getAWaiters( cmp );
>> bWaiters = getAWaiters( cmp );
>> assert(visitors >= aWaiters + bWaiters);
>> waiters = !b ? aWaiters : bWaiters;
>>
>> static
>> char const *const throwTable[] =
>> {
>> nullptr /* 0000 */, nullptr /* 0001 */, nullptr /* 0010 */,
>> nullptr /* 0011 */, nullptr /* 0100 */, nullptr /* 0101 */,
>> "monitor::wait() - number of visitors and a-waiters too
>> large", // 0110
>> "monitor::wait() - number of visitors and a-waiters too
>> large", // 0111
>> nullptr /* 1000 */, nullptr /* 1001 */, nullptr /* 1010 */,
>> nullptr /* 1011 */, nullptr /* 1100 */,
>> "monitor::wait() - number of visitors and b-waiters too
>> large", // 1101
>> nullptr, // 1110
>> "monitor::wait() - number of visitors and b-waiters too
>> large", // 1111
>> };
>> size_t maxVisitors = visitors == COUNTER_MASK,
>> maxAWaiters = aWaiters == COUNTER_MASK,
>> maxBWaiters = bWaiters == COUNTER_MASK;
>> size_t throwIdx = (size_t)b << 3 | maxVisitors << 2 |
>> maxAWaiters << 1 | maxBWaiters;
>> if( throwTable[throwIdx] )
>> {
>> m_tid = thread_id::self();
>> throw out_of_range( throwTable[throwIdx] );
>> };
>>
>> if( visitors > waiters )
>> // waiters < COUNTER_MASK because visitors > waiters
>> // taking over visitor-counter from another thread
>> chg = cmp + (!b ? WAITER_A_VALUE : WAITER_B_VALUE);
>> else
>> // visitors == aWaiters + bWaiters
>> chg = (cmp & ~OWNER_MASK) + (!b ? WAITER_A_VALUE :
>> WAITER_B_VALUE) + VISITOR_VALUE;
>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, chg,
>> memory_order_release, memory_order_relaxed ) );
> [...]
>
> Humm... For some reason I feel the need for std::memory_order_acq_rel
> here wrt the cas. ...
No, you only write nonsense. When I wait the lock is released,
so it's release-consistency.
You always write nonsense.
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2021-09-27 10:54 -0700 |
| Message-ID | <sit0gn$1pq$1@redfloyd.dont-email.me> |
| In reply to | #81621 |
On 9/27/2021 5:44 AM, Bonita Montero wrote: [redacted] > > No, you only write nonsense. When I wait the lock is released, > so it's release-consistency. > > You always write nonsense. If you're going to ask for opinions and then reject any criticism as nonsense, then why the heck are you even bothering to post your code?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-27 14:10 -0700 |
| Message-ID | <sitbvm$195u$1@gioia.aioe.org> |
| In reply to | #81625 |
On 9/27/2021 10:54 AM, red floyd wrote: > On 9/27/2021 5:44 AM, Bonita Montero wrote: > [redacted] >> >> No, you only write nonsense. When I wait the lock is released, >> so it's release-consistency. >> >> You always write nonsense. > > If you're going to ask for opinions and then reject any criticism > as nonsense, then why the heck are you even bothering to post your > code? Yeah, no shi%. Wow. Fwiw, its been a while since I have worked on such things. I just need to port Bonita's code over to Relacy, and give it a go in the simulator. It can find obscure memory order issues pretty damn fast. The problem is that I need to find the time. I mean, Bonita is not paying me. ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-27 14:06 -0700 |
| Message-ID | <sitboe$15oh$1@gioia.aioe.org> |
| In reply to | #81621 |
On 9/27/2021 5:44 AM, Bonita Montero wrote: > Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson: >> On 9/20/2021 1:43 PM, Bonita Montero wrote: >>> In some code I've to check different sates for which an exception might >>> be thrown. These states are all true or false so I combined them to a >>> four bit pattern wich I used as an index to a table which stores the >>> strings of the out_of_range exception to be trown or a nullptr if the >>> state isn't associated with an out of range condition. This helps me >>> to prevent some if-else-cascades and speeds up the code. >>> So this is the complete function but i put two empty lines around the >>> code I mentioned. >>> >>> void dual_monitor::wait( bool b ) [...] >>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>> memory_order_release, memory_order_relaxed ) ); >> [...] >> >> Humm... For some reason I feel the need for std::memory_order_acq_rel >> here wrt the cas. ... > > No, you only write nonsense. When I wait the lock is released, > so it's release-consistency. > > You always write nonsense. Decrementing a semaphore requires acquire semantics. Incrementing a semaphore requires release semantics. Trying to do both at once in a single atomic operation requires acquire/release semantics. I still need to port it to Relacy, but it seems like you need acq_rel here.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-27 16:09 -0700 |
| Message-ID | <sitiuu$1o5e$1@gioia.aioe.org> |
| In reply to | #81628 |
On 9/27/2021 2:06 PM, Chris M. Thomasson wrote: > On 9/27/2021 5:44 AM, Bonita Montero wrote: >> Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson: >>> On 9/20/2021 1:43 PM, Bonita Montero wrote: >>>> In some code I've to check different sates for which an exception might >>>> be thrown. These states are all true or false so I combined them to a >>>> four bit pattern wich I used as an index to a table which stores the >>>> strings of the out_of_range exception to be trown or a nullptr if the >>>> state isn't associated with an out of range condition. This helps me >>>> to prevent some if-else-cascades and speeds up the code. >>>> So this is the complete function but i put two empty lines around the >>>> code I mentioned. >>>> >>>> void dual_monitor::wait( bool b ) > [...] >>>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>> memory_order_release, memory_order_relaxed ) ); >>> [...] >>> >>> Humm... For some reason I feel the need for std::memory_order_acq_rel >>> here wrt the cas. ... >> >> No, you only write nonsense. When I wait the lock is released, >> so it's release-consistency. >> >> You always write nonsense. > > Decrementing a semaphore requires acquire semantics. Incrementing a > semaphore requires release semantics. Trying to do both at once in a > single atomic operation requires acquire/release semantics. > > I still need to port it to Relacy, but it seems like you need acq_rel here. Think about it... Waiting for something, implies acquire semantics.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-09-28 06:57 +0200 |
| Message-ID | <siu7bn$pai$2@dont-email.me> |
| In reply to | #81632 |
Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson: > On 9/27/2021 2:06 PM, Chris M. Thomasson wrote: >> On 9/27/2021 5:44 AM, Bonita Montero wrote: >>> Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson: >>>> On 9/20/2021 1:43 PM, Bonita Montero wrote: >>>>> In some code I've to check different sates for which an exception >>>>> might >>>>> be thrown. These states are all true or false so I combined them to a >>>>> four bit pattern wich I used as an index to a table which stores the >>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>> state isn't associated with an out of range condition. This helps me >>>>> to prevent some if-else-cascades and speeds up the code. >>>>> So this is the complete function but i put two empty lines around the >>>>> code I mentioned. >>>>> >>>>> void dual_monitor::wait( bool b ) >> [...] >>>>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>> memory_order_release, memory_order_relaxed ) ); >>>> [...] >>>> >>>> Humm... For some reason I feel the need for >>>> std::memory_order_acq_rel here wrt the cas. ... >>> >>> No, you only write nonsense. When I wait the lock is released, >>> so it's release-consistency. >>> >>> You always write nonsense. >> >> Decrementing a semaphore requires acquire semantics. Incrementing a >> semaphore requires release semantics. Trying to do both at once in a >> single atomic operation requires acquire/release semantics. >> >> I still need to port it to Relacy, but it seems like you need acq_rel >> here. > > Think about it... Waiting for something, implies acquire semantics. No, when I release a lock and could have modified data, I need release-semantics.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-27 22:28 -0700 |
| Message-ID | <siu95p$efv$2@gioia.aioe.org> |
| In reply to | #81636 |
On 9/27/2021 9:57 PM, Bonita Montero wrote: > Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson: >> On 9/27/2021 2:06 PM, Chris M. Thomasson wrote: >>> On 9/27/2021 5:44 AM, Bonita Montero wrote: >>>> Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson: >>>>> On 9/20/2021 1:43 PM, Bonita Montero wrote: >>>>>> In some code I've to check different sates for which an exception >>>>>> might >>>>>> be thrown. These states are all true or false so I combined them to a >>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>> strings of the out_of_range exception to be trown or a nullptr if the >>>>>> state isn't associated with an out of range condition. This helps me >>>>>> to prevent some if-else-cascades and speeds up the code. >>>>>> So this is the complete function but i put two empty lines around the >>>>>> code I mentioned. >>>>>> >>>>>> void dual_monitor::wait( bool b ) >>> [...] >>>>>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>>> memory_order_release, memory_order_relaxed ) ); >>>>> [...] >>>>> >>>>> Humm... For some reason I feel the need for >>>>> std::memory_order_acq_rel here wrt the cas. ... >>>> >>>> No, you only write nonsense. When I wait the lock is released, >>>> so it's release-consistency. >>>> >>>> You always write nonsense. >>> >>> Decrementing a semaphore requires acquire semantics. Incrementing a >>> semaphore requires release semantics. Trying to do both at once in a >>> single atomic operation requires acquire/release semantics. >>> >>> I still need to port it to Relacy, but it seems like you need acq_rel >>> here. >> >> Think about it... Waiting for something, implies acquire semantics. > > No, when I release a lock and could have modified data, > I need release-semantics. So, how can one utilize dual_monitor::wait? Does it wait on something?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-09-28 08:33 +0200 |
| Message-ID | <siud0e$pa3$2@dont-email.me> |
| In reply to | #81639 |
Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson: > On 9/27/2021 9:57 PM, Bonita Montero wrote: >> Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson: >>> On 9/27/2021 2:06 PM, Chris M. Thomasson wrote: >>>> On 9/27/2021 5:44 AM, Bonita Montero wrote: >>>>> Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson: >>>>>> On 9/20/2021 1:43 PM, Bonita Montero wrote: >>>>>>> In some code I've to check different sates for which an exception >>>>>>> might >>>>>>> be thrown. These states are all true or false so I combined them >>>>>>> to a >>>>>>> four bit pattern wich I used as an index to a table which stores the >>>>>>> strings of the out_of_range exception to be trown or a nullptr if >>>>>>> the >>>>>>> state isn't associated with an out of range condition. This helps me >>>>>>> to prevent some if-else-cascades and speeds up the code. >>>>>>> So this is the complete function but i put two empty lines around >>>>>>> the >>>>>>> code I mentioned. >>>>>>> >>>>>>> void dual_monitor::wait( bool b ) >>>> [...] >>>>>>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, chg, >>>>>>> memory_order_release, memory_order_relaxed ) ); >>>>>> [...] >>>>>> >>>>>> Humm... For some reason I feel the need for >>>>>> std::memory_order_acq_rel here wrt the cas. ... >>>>> >>>>> No, you only write nonsense. When I wait the lock is released, >>>>> so it's release-consistency. >>>>> >>>>> You always write nonsense. >>>> >>>> Decrementing a semaphore requires acquire semantics. Incrementing a >>>> semaphore requires release semantics. Trying to do both at once in a >>>> single atomic operation requires acquire/release semantics. >>>> >>>> I still need to port it to Relacy, but it seems like you need >>>> acq_rel here. >>> >>> Think about it... Waiting for something, implies acquire semantics. >> >> No, when I release a lock and could have modified data, >> I need release-semantics. > > So, how can one utilize dual_monitor::wait? Does it wait on something? Its like waiting on a condvar, which might have modified any data before.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-28 00:03 -0700 |
| Message-ID | <siueo2$k9l$1@gioia.aioe.org> |
| In reply to | #81643 |
On 9/27/2021 11:33 PM, Bonita Montero wrote: > Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson: >> On 9/27/2021 9:57 PM, Bonita Montero wrote: >>> Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson: >>>> On 9/27/2021 2:06 PM, Chris M. Thomasson wrote: >>>>> On 9/27/2021 5:44 AM, Bonita Montero wrote: >>>>>> Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson: >>>>>>> On 9/20/2021 1:43 PM, Bonita Montero wrote: >>>>>>>> In some code I've to check different sates for which an >>>>>>>> exception might >>>>>>>> be thrown. These states are all true or false so I combined them >>>>>>>> to a >>>>>>>> four bit pattern wich I used as an index to a table which stores >>>>>>>> the >>>>>>>> strings of the out_of_range exception to be trown or a nullptr >>>>>>>> if the >>>>>>>> state isn't associated with an out of range condition. This >>>>>>>> helps me >>>>>>>> to prevent some if-else-cascades and speeds up the code. >>>>>>>> So this is the complete function but i put two empty lines >>>>>>>> around the >>>>>>>> code I mentioned. >>>>>>>> >>>>>>>> void dual_monitor::wait( bool b ) >>>>> [...] >>>>>>>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, >>>>>>>> chg, memory_order_release, memory_order_relaxed ) ); >>>>>>> [...] >>>>>>> >>>>>>> Humm... For some reason I feel the need for >>>>>>> std::memory_order_acq_rel here wrt the cas. ... >>>>>> >>>>>> No, you only write nonsense. When I wait the lock is released, >>>>>> so it's release-consistency. >>>>>> >>>>>> You always write nonsense. >>>>> >>>>> Decrementing a semaphore requires acquire semantics. Incrementing a >>>>> semaphore requires release semantics. Trying to do both at once in >>>>> a single atomic operation requires acquire/release semantics. >>>>> >>>>> I still need to port it to Relacy, but it seems like you need >>>>> acq_rel here. >>>> >>>> Think about it... Waiting for something, implies acquire semantics. >>> >>> No, when I release a lock and could have modified data, >>> I need release-semantics. >> >> So, how can one utilize dual_monitor::wait? Does it wait on something? > > Its like waiting on a condvar, which might have modified any data > before. > I was thinking along those lines. However, waiting on a condvar involves several steps. It also involves reacquiring the mutex...
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-09-28 12:05 +0200 |
| Message-ID | <siupd6$edh$1@dont-email.me> |
| In reply to | #81645 |
Am 28.09.2021 um 09:03 schrieb Chris M. Thomasson: > On 9/27/2021 11:33 PM, Bonita Montero wrote: >> Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson: >>> On 9/27/2021 9:57 PM, Bonita Montero wrote: >>>> Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson: >>>>> On 9/27/2021 2:06 PM, Chris M. Thomasson wrote: >>>>>> On 9/27/2021 5:44 AM, Bonita Montero wrote: >>>>>>> Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson: >>>>>>>> On 9/20/2021 1:43 PM, Bonita Montero wrote: >>>>>>>>> In some code I've to check different sates for which an >>>>>>>>> exception might >>>>>>>>> be thrown. These states are all true or false so I combined >>>>>>>>> them to a >>>>>>>>> four bit pattern wich I used as an index to a table which >>>>>>>>> stores the >>>>>>>>> strings of the out_of_range exception to be trown or a nullptr >>>>>>>>> if the >>>>>>>>> state isn't associated with an out of range condition. This >>>>>>>>> helps me >>>>>>>>> to prevent some if-else-cascades and speeds up the code. >>>>>>>>> So this is the complete function but i put two empty lines >>>>>>>>> around the >>>>>>>>> code I mentioned. >>>>>>>>> >>>>>>>>> void dual_monitor::wait( bool b ) >>>>>> [...] >>>>>>>>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, >>>>>>>>> chg, memory_order_release, memory_order_relaxed ) ); >>>>>>>> [...] >>>>>>>> >>>>>>>> Humm... For some reason I feel the need for >>>>>>>> std::memory_order_acq_rel here wrt the cas. ... >>>>>>> >>>>>>> No, you only write nonsense. When I wait the lock is released, >>>>>>> so it's release-consistency. >>>>>>> >>>>>>> You always write nonsense. >>>>>> >>>>>> Decrementing a semaphore requires acquire semantics. Incrementing >>>>>> a semaphore requires release semantics. Trying to do both at once >>>>>> in a single atomic operation requires acquire/release semantics. >>>>>> >>>>>> I still need to port it to Relacy, but it seems like you need >>>>>> acq_rel here. >>>>> >>>>> Think about it... Waiting for something, implies acquire semantics. >>>> >>>> No, when I release a lock and could have modified data, >>>> I need release-semantics. >>> >>> So, how can one utilize dual_monitor::wait? Does it wait on something? >> >> Its like waiting on a condvar, which might have modified any data >> before. >> > > I was thinking along those lines. However, waiting on a condvar involves > several steps. It also involves reacquiring the mutex... With what I do the reacquisition is done by the side that unlocks the mutex. It simply keeps the locked-flag while unlocking and sets the visitor-event.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-29 21:57 -0700 |
| Message-ID | <sj3g3d$i6k$1@gioia.aioe.org> |
| In reply to | #81649 |
On 9/28/2021 3:05 AM, Bonita Montero wrote: > Am 28.09.2021 um 09:03 schrieb Chris M. Thomasson: >> On 9/27/2021 11:33 PM, Bonita Montero wrote: >>> Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson: >>>> On 9/27/2021 9:57 PM, Bonita Montero wrote: >>>>> Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson: >>>>>> On 9/27/2021 2:06 PM, Chris M. Thomasson wrote: >>>>>>> On 9/27/2021 5:44 AM, Bonita Montero wrote: >>>>>>>> Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson: >>>>>>>>> On 9/20/2021 1:43 PM, Bonita Montero wrote: >>>>>>>>>> In some code I've to check different sates for which an >>>>>>>>>> exception might >>>>>>>>>> be thrown. These states are all true or false so I combined >>>>>>>>>> them to a >>>>>>>>>> four bit pattern wich I used as an index to a table which >>>>>>>>>> stores the >>>>>>>>>> strings of the out_of_range exception to be trown or a nullptr >>>>>>>>>> if the >>>>>>>>>> state isn't associated with an out of range condition. This >>>>>>>>>> helps me >>>>>>>>>> to prevent some if-else-cascades and speeds up the code. >>>>>>>>>> So this is the complete function but i put two empty lines >>>>>>>>>> around the >>>>>>>>>> code I mentioned. >>>>>>>>>> >>>>>>>>>> void dual_monitor::wait( bool b ) >>>>>>> [...] >>>>>>>>>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, >>>>>>>>>> chg, memory_order_release, memory_order_relaxed ) ); >>>>>>>>> [...] >>>>>>>>> >>>>>>>>> Humm... For some reason I feel the need for >>>>>>>>> std::memory_order_acq_rel here wrt the cas. ... >>>>>>>> >>>>>>>> No, you only write nonsense. When I wait the lock is released, >>>>>>>> so it's release-consistency. >>>>>>>> >>>>>>>> You always write nonsense. >>>>>>> >>>>>>> Decrementing a semaphore requires acquire semantics. Incrementing >>>>>>> a semaphore requires release semantics. Trying to do both at once >>>>>>> in a single atomic operation requires acquire/release semantics. >>>>>>> >>>>>>> I still need to port it to Relacy, but it seems like you need >>>>>>> acq_rel here. >>>>>> >>>>>> Think about it... Waiting for something, implies acquire semantics. >>>>> >>>>> No, when I release a lock and could have modified data, >>>>> I need release-semantics. >>>> >>>> So, how can one utilize dual_monitor::wait? Does it wait on something? >>> >>> Its like waiting on a condvar, which might have modified any data >>> before. >>> >> >> I was thinking along those lines. However, waiting on a condvar >> involves several steps. It also involves reacquiring the mutex... > > With what I do the reacquisition is done by the side that unlocks the > mutex. It simply keeps the locked-flag while unlocking and sets the > visitor-event. Where are your example use cases for dual_monitor? I cannot find all of the code for dual_monitor anyway. So, its difficult for me to port to a simulator and use... Just make a new thread, with an example program that uses dual_monitor.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-09-30 08:16 +0200 |
| Message-ID | <sj3ko4$ddo$1@dont-email.me> |
| In reply to | #81687 |
Am 30.09.2021 um 06:57 schrieb Chris M. Thomasson: > On 9/28/2021 3:05 AM, Bonita Montero wrote: >> Am 28.09.2021 um 09:03 schrieb Chris M. Thomasson: >>> On 9/27/2021 11:33 PM, Bonita Montero wrote: >>>> Am 28.09.2021 um 07:28 schrieb Chris M. Thomasson: >>>>> On 9/27/2021 9:57 PM, Bonita Montero wrote: >>>>>> Am 28.09.2021 um 01:09 schrieb Chris M. Thomasson: >>>>>>> On 9/27/2021 2:06 PM, Chris M. Thomasson wrote: >>>>>>>> On 9/27/2021 5:44 AM, Bonita Montero wrote: >>>>>>>>> Am 27.09.2021 um 09:18 schrieb Chris M. Thomasson: >>>>>>>>>> On 9/20/2021 1:43 PM, Bonita Montero wrote: >>>>>>>>>>> In some code I've to check different sates for which an >>>>>>>>>>> exception might >>>>>>>>>>> be thrown. These states are all true or false so I combined >>>>>>>>>>> them to a >>>>>>>>>>> four bit pattern wich I used as an index to a table which >>>>>>>>>>> stores the >>>>>>>>>>> strings of the out_of_range exception to be trown or a >>>>>>>>>>> nullptr if the >>>>>>>>>>> state isn't associated with an out of range condition. This >>>>>>>>>>> helps me >>>>>>>>>>> to prevent some if-else-cascades and speeds up the code. >>>>>>>>>>> So this is the complete function but i put two empty lines >>>>>>>>>>> around the >>>>>>>>>>> code I mentioned. >>>>>>>>>>> >>>>>>>>>>> void dual_monitor::wait( bool b ) >>>>>>>> [...] >>>>>>>>>>> } while( !m_flagAndCounters.compare_exchange_weak( cmp, >>>>>>>>>>> chg, memory_order_release, memory_order_relaxed ) ); >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Humm... For some reason I feel the need for >>>>>>>>>> std::memory_order_acq_rel here wrt the cas. ... >>>>>>>>> >>>>>>>>> No, you only write nonsense. When I wait the lock is released, >>>>>>>>> so it's release-consistency. >>>>>>>>> >>>>>>>>> You always write nonsense. >>>>>>>> >>>>>>>> Decrementing a semaphore requires acquire semantics. >>>>>>>> Incrementing a semaphore requires release semantics. Trying to >>>>>>>> do both at once in a single atomic operation requires >>>>>>>> acquire/release semantics. >>>>>>>> >>>>>>>> I still need to port it to Relacy, but it seems like you need >>>>>>>> acq_rel here. >>>>>>> >>>>>>> Think about it... Waiting for something, implies acquire semantics. >>>>>> >>>>>> No, when I release a lock and could have modified data, >>>>>> I need release-semantics. >>>>> >>>>> So, how can one utilize dual_monitor::wait? Does it wait on something? >>>> >>>> Its like waiting on a condvar, which might have modified any data >>>> before. >>>> >>> >>> I was thinking along those lines. However, waiting on a condvar >>> involves several steps. It also involves reacquiring the mutex... >> >> With what I do the reacquisition is done by the side that unlocks the >> mutex. It simply keeps the locked-flag while unlocking and sets the >> visitor-event. > > Where are your example use cases for dual_monitor? ... It's usable when two threads communicate bidirectional.
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c++
csiph-web