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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-07 02:45 +0000 |
| Message-ID | <Hbt7J.85932$YW.69259@fx05.iad> |
| In reply to | #81895 |
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 10/6/2021 7:17 PM, Branimir Maksimovic wrote:
>> On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> ideal. A wait-free fast-path is even better!
>>>
>> Then, you have to think what to do, when there is is nothing
>> to do :P
>>
>
> When the fast-path fails, we can choose to try to wait. Usually on a
> Futex or Eventcount. The main idea is under periods of load, when the
> structure is not empty, we can fly along lock/wait-free paths.
iWhat you think about this code:
while(true){
usleep(1000) /// we dpn't want to overheat :P
/***
* interrestingly CAS doesn't work, because of
* some weird Apple memory scheme.
* OSAtomicCompareAndSwapPtr: doesn't work
*/
var val:UInt8 = 0
repeat {
usleep(1)
OSMemoryBarrier()
val = bval!.pointee!.load(as:UInt8.self)
}while ( val == 1 || val == 2)
OSMemoryBarrier()
bval!.pointee!.storeBytes(of:1,as: UInt8.self)
repeat {
usleep(1)
OSMemoryBarrier()
val = bval!.pointee!.load(as:UInt8.self)
}while ( val == 2)
OSMemoryBarrier()
bval!.pointee!.storeBytes(of:2,as: UInt8.self)
print("acquired")
/// payLoad
OSMemoryBarrier()
bval!.pointee!.storeBytes(of:0,as: UInt8.self)
print("releazed\n")
--
7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-06 20:01 -0700 |
| Message-ID | <sjlnub$bq2$1@gioia.aioe.org> |
| In reply to | #81896 |
On 10/6/2021 7:45 PM, Branimir Maksimovic wrote:
> On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 10/6/2021 7:17 PM, Branimir Maksimovic wrote:
>>> On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>> ideal. A wait-free fast-path is even better!
>>>>
>>> Then, you have to think what to do, when there is is nothing
>>> to do :P
>>>
>>
>> When the fast-path fails, we can choose to try to wait. Usually on a
>> Futex or Eventcount. The main idea is under periods of load, when the
>> structure is not empty, we can fly along lock/wait-free paths.
>
> iWhat you think about this code:
> while(true){
> usleep(1000) /// we dpn't want to overheat :P
> /***
> * interrestingly CAS doesn't work, because of
> * some weird Apple memory scheme.
> * OSAtomicCompareAndSwapPtr: doesn't work
> */
> var val:UInt8 = 0
> repeat {
> usleep(1)
> OSMemoryBarrier()
> val = bval!.pointee!.load(as:UInt8.self)
> }while ( val == 1 || val == 2)
> OSMemoryBarrier()
> bval!.pointee!.storeBytes(of:1,as: UInt8.self)
> repeat {
> usleep(1)
> OSMemoryBarrier()
> val = bval!.pointee!.load(as:UInt8.self)
> }while ( val == 2)
> OSMemoryBarrier()
> bval!.pointee!.storeBytes(of:2,as: UInt8.self)
> print("acquired")
> /// payLoad
> OSMemoryBarrier()
> bval!.pointee!.storeBytes(of:0,as: UInt8.self)
> print("releazed\n")
>
I need to really examine it, but it kind of reminds me of a way to load
things up in some sort of odd sequence lock. There is a shitload of
membars in there. Heck, is OSMemoryBarrier akin to a #StoreLoad |
#LoadStore | #Load#Load | #Store#Store on the SPARC, in other words seq
order? Humm... I cannot believe that CAS does not work! What does
std::atomic<T>::compare_exchange_weak() with a membar of
std::memory_order_relaxed disassemble into?
Btw, a seqlock is:
https://en.wikipedia.org/wiki/Seqlock
If OSMemoryBarrier is seq_order this this should go really slow.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-07 03:24 +0000 |
| Message-ID | <dMt7J.175462$o45.109740@fx46.iad> |
| In reply to | #81897 |
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > order? Humm... I cannot believe that CAS does not work! What does > std::atomic<T>::compare_exchange_weak() with a membar of > std::memory_order_relaxed disassemble into? Problem is OS, how it maps memory. I didn't figured out why, but simply value is not readed, that is, if I do it in assembler, it would probably work, but I have tried to do it in HLL :P This is M1, but I think it is more related to OS... Haven't tried C++ though :P -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-08 13:13 -0700 |
| Message-ID | <sjq8q6$1l3$1@gioia.aioe.org> |
| In reply to | #81898 |
On 10/6/2021 8:24 PM, Branimir Maksimovic wrote: > On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> order? Humm... I cannot believe that CAS does not work! What does >> std::atomic<T>::compare_exchange_weak() with a membar of >> std::memory_order_relaxed disassemble into? > Problem is OS, how it maps memory. I didn't figured out why, > but simply value is not readed, that is, if I do it in assembler, > it would probably work, but I have tried to do it in HLL :P > This is M1, but I think it is more related to OS... > Haven't tried C++ though :P > Try to get a disassembly of std::atomic<T>::compare_exchange_weak() on your system. Start with an unsigned int. I am interested!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-07 08:37 +0200 |
| Message-ID | <sjm4ii$uh$3@dont-email.me> |
| In reply to | #81890 |
Am 07.10.2021 um 02:19 schrieb Chris M. Thomasson: > On 10/2/2021 1:57 AM, Bonita Montero wrote: >> Am 02.10.2021 um 10:36 schrieb Chris M. Thomasson: >> >>> Why do you make me want to cough when I read some of your comments? >>> The idea is to try to minimize slow-paths... Think about it! Damn >>> it... ;^o >> >> The idea of lock-free algorithms is not to have slow paths at all. > > Why not? You have a very narrow view. A pure lock-free fast-path is > ideal. A wait-free fast-path is even better! That's not a narrow view but it is how it's defined.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-07 01:15 -0700 |
| Message-ID | <sjmaac$d4c$1@gioia.aioe.org> |
| In reply to | #81903 |
On 10/6/2021 11:37 PM, Bonita Montero wrote: > Am 07.10.2021 um 02:19 schrieb Chris M. Thomasson: >> On 10/2/2021 1:57 AM, Bonita Montero wrote: >>> Am 02.10.2021 um 10:36 schrieb Chris M. Thomasson: >>> >>>> Why do you make me want to cough when I read some of your comments? >>>> The idea is to try to minimize slow-paths... Think about it! Damn >>>> it... ;^o >>> >>> The idea of lock-free algorithms is not to have slow paths at all. >> >> Why not? You have a very narrow view. A pure lock-free fast-path is >> ideal. A wait-free fast-path is even better! > > That's not a narrow view but it is how it's defined. Yeah... Think outside of the box and use a lock/wait-free algorihtm for a fast-path, and use a Futex or Eventcount for the slow-path.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-07 12:16 +0200 |
| Message-ID | <sjmhdd$csk$2@dont-email.me> |
| In reply to | #81908 |
Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson: >> That's not a narrow view but it is how it's defined. > > Yeah... Think outside of the box and use a lock/wait-free algorihtm > for a fast-path, and use a Futex or Eventcount for the slow-path. Lock-free algorithms don't have a slow path. That's while they don't lock and you've to poll them.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-07 12:26 -0700 |
| Message-ID | <sjnhkq$1gvq$2@gioia.aioe.org> |
| In reply to | #81912 |
On 10/7/2021 3:16 AM, Bonita Montero wrote: > Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson: > >>> That's not a narrow view but it is how it's defined. >> >> Yeah... Think outside of the box and use a lock/wait-free algorihtm >> for a fast-path, and use a Futex or Eventcount for the slow-path. > > Lock-free algorithms don't have a slow path. > That's while they don't lock and you've to poll them. Why poll them? Add a slow-path using futex or eventcount... Is seems that you are having a hard time understanding this... This keeps the fast-path for periods of load, when sheer performance matters. Under load, the data-structure is much more likely to hit fast-paths, and reap the benefits from lock/wait free algorithms. Got it?
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-07 20:16 +0000 |
| Message-ID | <jAI7J.12565$fZ.6010@fx06.iad> |
| In reply to | #81915 |
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > On 10/7/2021 3:16 AM, Bonita Montero wrote: >> Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson: >> >>>> That's not a narrow view but it is how it's defined. >>> >>> Yeah... Think outside of the box and use a lock/wait-free algorihtm >>> for a fast-path, and use a Futex or Eventcount for the slow-path. >> >> Lock-free algorithms don't have a slow path. >> That's while they don't lock and you've to poll them. > > Why poll them? Add a slow-path using futex or eventcount... Is seems > that you are having a hard time understanding this... This keeps the > fast-path for periods of load, when sheer performance matters. Under > load, the data-structure is much more likely to hit fast-paths, and reap > the benefits from lock/wait free algorithms. Got it? Yeah, problem is when you don't have something usefull to do :P -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-07 14:27 -0700 |
| Message-ID | <sjnook$k9s$1@gioia.aioe.org> |
| In reply to | #81917 |
On 10/7/2021 1:16 PM, Branimir Maksimovic wrote:
> On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 10/7/2021 3:16 AM, Bonita Montero wrote:
>>> Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
>>>
>>>>> That's not a narrow view but it is how it's defined.
>>>>
>>>> Yeah... Think outside of the box and use a lock/wait-free algorihtm
>>>> for a fast-path, and use a Futex or Eventcount for the slow-path.
>>>
>>> Lock-free algorithms don't have a slow path.
>>> That's while they don't lock and you've to poll them.
>>
>> Why poll them? Add a slow-path using futex or eventcount... Is seems
>> that you are having a hard time understanding this... This keeps the
>> fast-path for periods of load, when sheer performance matters. Under
>> load, the data-structure is much more likely to hit fast-paths, and reap
>> the benefits from lock/wait free algorithms. Got it?
> Yeah, problem is when you don't have something usefull to do :P
>
>
Indeed. There is a funny way to use try_lock to try to gain this sort of
pattern... Iirc, it went something like:
__________________________
void lock()
{
while (! try_lock())
{
if (! try_to_do_something_else())
{
lock();
break;
}
}
}
__________________________
So, if something else was done, we can try_lock again. Iirc, I even put
a limit on how many times try_lock() can be called. Akin to an adaptive
mutex, except instead of spinning, we see if something else can be done.
It does work in certain scenarios and/or setups...
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-07 23:27 +0000 |
| Message-ID | <onL7J.103833$jl2.79843@fx34.iad> |
| In reply to | #81918 |
On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 10/7/2021 1:16 PM, Branimir Maksimovic wrote:
>> On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> On 10/7/2021 3:16 AM, Bonita Montero wrote:
>>>> Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
>>>>
>>>>>> That's not a narrow view but it is how it's defined.
>>>>>
>>>>> Yeah... Think outside of the box and use a lock/wait-free algorihtm for
>>>>> a fast-path, and use a Futex or Eventcount for the slow-path.
>>>>
>>>> Lock-free algorithms don't have a slow path. That's while they don't lock
>>>> and you've to poll them.
>>>
>>> Why poll them? Add a slow-path using futex or eventcount... Is seems that
>>> you are having a hard time understanding this... This keeps the fast-path
>>> for periods of load, when sheer performance matters. Under load, the
>>> data-structure is much more likely to hit fast-paths, and reap the benefits
>>> from lock/wait free algorithms. Got it?
>> Yeah, problem is when you don't have something usefull to do :P
>>
>>
>
> Indeed. There is a funny way to use try_lock to try to gain this sort of
> pattern... Iirc, it went something like: __________________________ void
> lock() { while (! try_lock()) { if (! try_to_do_something_else()) { lock();
> break; } } } __________________________
>
> So, if something else was done, we can try_lock again. Iirc, I even put a
> limit on how many times try_lock() can be called. Akin to an adaptive mutex,
> except instead of spinning, we see if something else can be done.
>
> It does work in certain scenarios and/or setups...
You have *understanding* :P
Thanks!
--
7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-08 15:24 -0700 |
| Message-ID | <sjqget$pbc$1@gioia.aioe.org> |
| In reply to | #81918 |
On 10/7/2021 2:27 PM, Chris M. Thomasson wrote:
> On 10/7/2021 1:16 PM, Branimir Maksimovic wrote:
>> On 2021-10-07, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> On 10/7/2021 3:16 AM, Bonita Montero wrote:
>>>> Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson:
>>>>
>>>>>> That's not a narrow view but it is how it's defined.
>>>>>
>>>>> Yeah... Think outside of the box and use a lock/wait-free algorihtm
>>>>> for a fast-path, and use a Futex or Eventcount for the slow-path.
>>>>
>>>> Lock-free algorithms don't have a slow path.
>>>> That's while they don't lock and you've to poll them.
>>>
>>> Why poll them? Add a slow-path using futex or eventcount... Is seems
>>> that you are having a hard time understanding this... This keeps the
>>> fast-path for periods of load, when sheer performance matters. Under
>>> load, the data-structure is much more likely to hit fast-paths, and reap
>>> the benefits from lock/wait free algorithms. Got it?
>> Yeah, problem is when you don't have something usefull to do :P
>>
>>
>
> Indeed. There is a funny way to use try_lock to try to gain this sort of
> pattern... Iirc, it went something like:
> __________________________
> void lock()
> {
> while (! try_lock())
> {
> if (! try_to_do_something_else())
> {
> lock();
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oh crap. I did not mean to imply recursion here! Let me fix that:
__________________________
void my_custom_lock()
{
while (! try_lock())
{
if (! try_to_do_something_else())
{
lock();
break;
}
}
}
__________________________
There, now there is no possibility of recursion in my pseudo-code. Sorry
for any confusion! Ouch! ;^o
> break;
> }
> }
> }
> __________________________
>
> So, if something else was done, we can try_lock again. Iirc, I even put
> a limit on how many times try_lock() can be called. Akin to an adaptive
> mutex, except instead of spinning, we see if something else can be done.
>
> It does work in certain scenarios and/or setups...
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-08 07:53 +0200 |
| Message-ID | <sjomcb$750$2@dont-email.me> |
| In reply to | #81915 |
Am 07.10.2021 um 21:26 schrieb Chris M. Thomasson: > On 10/7/2021 3:16 AM, Bonita Montero wrote: >> Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson: >> >>>> That's not a narrow view but it is how it's defined. >>> >>> Yeah... Think outside of the box and use a lock/wait-free algorihtm >>> for a fast-path, and use a Futex or Eventcount for the slow-path. >> >> Lock-free algorithms don't have a slow path. >> That's while they don't lock and you've to poll them. > > Why poll them? ... Because they are lock-free. > Add a slow-path using futex or eventcount... Then they aren't lock-free anymore.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-08 12:53 -0700 |
| Message-ID | <sjq7jv$1dsa$1@gioia.aioe.org> |
| In reply to | #81924 |
On 10/7/2021 10:53 PM, Bonita Montero wrote: > Am 07.10.2021 um 21:26 schrieb Chris M. Thomasson: >> On 10/7/2021 3:16 AM, Bonita Montero wrote: >>> Am 07.10.2021 um 10:15 schrieb Chris M. Thomasson: >>> >>>>> That's not a narrow view but it is how it's defined. >>>> >>>> Yeah... Think outside of the box and use a lock/wait-free algorihtm >>>> for a fast-path, and use a Futex or Eventcount for the slow-path. >>> >>> Lock-free algorithms don't have a slow path. >>> That's while they don't lock and you've to poll them. >> >> Why poll them? ... > > Because they are lock-free. Sigh... Polling is inefficient waiting, in a sense. Anyway... > >> Add a slow-path using futex or eventcount... > > Then they aren't lock-free anymore. > Oh well. I tried everybody. She does not seem to get it. Shit happens.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-01 13:08 +0000 |
| Message-ID | <qLD5J.70145$tG6.53975@fx39.iad> |
| In reply to | #81695 |
On 2021-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson: >> On 9/30/2021 3:39 AM, Bonita Montero wrote: >>>> That's a bit vague. One can create highly efficient bidirectional >>>> communication between two threads using two wait-free >>>> single-producer/single-consumer queues without using any atomic >>>> RMW's, just atomic loads, stores, and some some cleverly placed membars. >>> >>> When you use wait-free or lock-free algorithms and there's no data >>> you have to poll. >> >> Why? > > Because you don't have to wait in the kernel. > If you don't spin it is not lock :P problem is that only way you don't synchronize is when things are *independent* from each other :P -- 7-77-777 Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-02 00:31 -0700 |
| Message-ID | <sj91ta$1fi7$3@gioia.aioe.org> |
| In reply to | #81700 |
On 10/1/2021 6:08 AM, Branimir Maksimovic wrote: > On 2021-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson: >>> On 9/30/2021 3:39 AM, Bonita Montero wrote: >>>>> That's a bit vague. One can create highly efficient bidirectional >>>>> communication between two threads using two wait-free >>>>> single-producer/single-consumer queues without using any atomic >>>>> RMW's, just atomic loads, stores, and some some cleverly placed membars. >>>> >>>> When you use wait-free or lock-free algorithms and there's no data >>>> you have to poll. >>> >>> Why? >> >> Because you don't have to wait in the kernel. >> > If you don't spin it is not lock :P True. Hitting the fast path is very nice indeed! > problem is that only way you don't synchronize > is when things are *independent* from each other :P > Well, sometimes one can do other things instead of spinning/waiting, even in a mutex locked condition. Its an interesting simple logic loop. You have probably seen it before.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-02 00:52 -0700 |
| Message-ID | <sj933l$4q6$1@gioia.aioe.org> |
| In reply to | #81773 |
On 10/2/2021 12:31 AM, Chris M. Thomasson wrote:
> On 10/1/2021 6:08 AM, Branimir Maksimovic wrote:
>> On 2021-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 30.09.2021 um 22:20 schrieb Chris M. Thomasson:
>>>> On 9/30/2021 3:39 AM, Bonita Montero wrote:
>>>>>> That's a bit vague. One can create highly efficient bidirectional
>>>>>> communication between two threads using two wait-free
>>>>>> single-producer/single-consumer queues without using any atomic
>>>>>> RMW's, just atomic loads, stores, and some some cleverly placed
>>>>>> membars.
>>>>>
>>>>> When you use wait-free or lock-free algorithms and there's no data
>>>>> you have to poll.
>>>>
>>>> Why?
>>>
>>> Because you don't have to wait in the kernel.
>>>
>> If you don't spin it is not lock :P
>
> True. Hitting the fast path is very nice indeed!
>
>> problem is that only way you don't synchronize
>> is when things are *independent* from each other :P
>>
>
> Well, sometimes one can do other things instead of spinning/waiting,
> even in a mutex locked condition. Its an interesting simple logic loop.
> You have probably seen it before.
>
Off the top of my head, here is some crude pseudocode to try to get
across what I am referring to, verbose and not very pretty, fairly
simple wrt a way to lock a mutex. This was from a long time ago. Fairly
adaptive:
___________________________
for (unsigned long i = 0; i < 42; ++i)
{
if (try_lock()) return;
if (! try_to_do_something_else()) break;
}
lock();
___________________________
We can try to do other things before we actually wait on the lock. It
does work, in certain setups.
This logic above is the most basic I can break it down to.
Even something that simple can help get things done, "quicker" so to
speak. The thread tries to do something else, before it waits. It can be
made to work. And if it fits in with the code at hand, the use case, the
system we are working on, well, it can be good!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-09-28 06:55 +0200 |
| Message-ID | <siu78m$pai$1@dont-email.me> |
| In reply to | #81628 |
Am 27.09.2021 um 23:06 schrieb Chris M. Thomasson: > 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. No, I could have modified data before, so I need, release-semantics. You are such a n00b.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-27 22:27 -0700 |
| Message-ID | <siu93u$efv$1@gioia.aioe.org> |
| In reply to | #81635 |
On 9/27/2021 9:55 PM, Bonita Montero wrote: > Am 27.09.2021 um 23:06 schrieb Chris M. Thomasson: >> 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. > > No, I could have modified data before, so I need, release-semantics. > You are such a n00b. For some reason when I saw the word "wait", I think of acquire. Are you sure you know all about memory barriers? I have worked with them in the past.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-27 22:49 -0700 |
| Message-ID | <siuadb$r5v$1@gioia.aioe.org> |
| In reply to | #81638 |
On 9/27/2021 10:27 PM, Chris M. Thomasson wrote: > On 9/27/2021 9:55 PM, Bonita Montero wrote: >> Am 27.09.2021 um 23:06 schrieb Chris M. Thomasson: >>> 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. >> >> No, I could have modified data before, so I need, release-semantics. >> You are such a n00b. Waiting on something is acquire by nature. Show me where its not? Actually, show me where to place the acquire and release barriers in a semaphore? Can you do it? Should be a piece of cake, right? > > For some reason when I saw the word "wait", I think of acquire. Are you > sure you know all about memory barriers? I have worked with them in the > past.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c++
csiph-web