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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-30 01:19 -0700 |
| Message-ID | <sj3ru9$17i1$1@gioia.aioe.org> |
| In reply to | #81688 |
On 9/29/2021 11:16 PM, Bonita Montero wrote: > 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. 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. Now, if one needs to be able to wait on them, well that's a different story. This makes me think about eventcounts; I have plenty of experience with those. God I am getting older. Actually, I am wondering if you happen to be familiar with the good ol' two lock queue? I first saw it decades ago: https://www.cs.rochester.edu/~scott/papers/1996_PODC_queues.pdf A classic! The queues in that paper are well known in lock-free circles... Beware... There are subtle memory lifetime issues that can occur in the lock-free version. Basically, the same horror show that can occur in a lock-free stack. Its not just ABA, its making sure that the memory is valid for a certain operation. Iirc, Windows does something funky with SEH to get this to work in their SList API. ;^)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-09-30 12:39 +0200 |
| Message-ID | <sj4450$1arb$1@gioia.aioe.org> |
| In reply to | #81690 |
> 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. That makes wait-free and lock-free algorithms out of the question. The only lock-free algorihm which ware practicable are lock-free stacks. You can use them for pooling objects or to give back items to a thread which has allocated the items so that ther's no need for a common lock - all modern memory-allocators give back blocks freed bei foreign threads to the thread to whose pool the blocks belongs.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-09-30 13:20 -0700 |
| Message-ID | <sj566a$1e1s$4@gioia.aioe.org> |
| In reply to | #81692 |
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? [...]
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-01 03:32 +0200 |
| Message-ID | <sj5oeg$hnq$1@dont-email.me> |
| In reply to | #81694 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-10-01 04:43 -0700 |
| Message-ID | <5312c1e3-ce2b-4c78-80e4-02ea4a90e393n@googlegroups.com> |
| In reply to | #81695 |
On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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. What a thread does when its input queue is empty?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-01 14:59 +0200 |
| Message-ID | <sj70mt$g5k$1@dont-email.me> |
| In reply to | #81697 |
Am 01.10.2021 um 13:43 schrieb Öö Tiib: > On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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. > > What a thread does when its input queue is empty? If it hasn't anything other to do than "waiting" for a new entry it spins. Lock-free and wait-free datastructures are idiocracy except from lock-free stacks.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-01 13:10 +0000 |
| Message-ID | <pND5J.70146$tG6.16112@fx39.iad> |
| In reply to | #81698 |
On 2021-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 01.10.2021 um 13:43 schrieb Öö Tiib: >> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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. >> >> What a thread does when its input queue is empty? > > If it hasn't anything other to do than "waiting" for a new entry it > spins. Lock-free and wait-free datastructures are idiocracy except > from lock-free stacks. Poof. you spin me around like a record? :P -- 7-77-777 Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 13:04 -0700 |
| Message-ID | <sj7pk6$v7e$1@gioia.aioe.org> |
| In reply to | #81698 |
On 10/1/2021 5:59 AM, Bonita Montero wrote: > Am 01.10.2021 um 13:43 schrieb Öö Tiib: >> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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. >> >> What a thread does when its input queue is empty? > > If it hasn't anything other to do than "waiting" for a new entry it > spins. Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic stack into account. When its empty we can use, say, a futex to wait on it. This would be the slow-path. A fast-path is when the stack is not empty. There is a big difference between a fast and a slow path. The former is lock-free, the latter might have to wait. This even works for wait-free structures. In this case, the fast-path would be wait-free. > Lock-free and wait-free datastructures are idiocracy except > from lock-free stacks. Sure. Whatever you say Bonita. Cough.... Cough... ;^)
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-01 20:53 +0000 |
| Message-ID | <VyK5J.212801$T_8.185707@fx48.iad> |
| In reply to | #81715 |
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 10/1/2021 5:59 AM, Bonita Montero wrote:
>> Am 01.10.2021 um 13:43 schrieb Öö Tiib:
>>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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.
>>>
>>> What a thread does when its input queue is empty?
>>
>> If it hasn't anything other to do than "waiting" for a new entry it spins.
>
> Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic stack
> into account. When its empty we can use, say, a futex to wait on it. This
> would be the slow-path. A fast-path is when the stack is not empty. There is
> a big difference between a fast and a slow path. The former is lock-free, the
> latter might have to wait.
>
> This even works for wait-free structures. In this case, the fast-path would
> be wait-free.
Watch out that "wait free" isn't just spining with more cpomplex algorithm
doing nothing usefull :P
here is mine mutex:
format elf64
FUTEX_WAIT equ 0
FUTEX_WAKE equ 1
FUTEX_PRIVATE_FLAG equ 128
public futex_acquire
public futex_release
futex_acquire:
push rbx
push r15
; push r10
mov r15,rdi
.L0:
mov ebx,1
xor eax,eax
lock cmpxchg [r15],ebx
test eax,eax
jz .L1
mov eax, 202
mov rdi, r15
mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG
mov edx, 1
xor r10,r10
syscall
jmp .L0
.L1:; pop r10
pop r15
pop rbx
ret
futex_release:
lock and dword[rdi],0
mov eax,202
; mov rdi, sema
mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG
mov edx,1
syscall
ret
>
>
>> Lock-free and wait-free datastructures are idiocracy except from lock-free
>> stacks.
>
> Sure. Whatever you say Bonita. Cough.... Cough... ;^)
Heh, rsyncing something, looking bloat and have no patience :p
--
7-77-777
Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 14:24 -0700 |
| Message-ID | <sj7u9o$q2t$1@gioia.aioe.org> |
| In reply to | #81720 |
On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:
> On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 10/1/2021 5:59 AM, Bonita Montero wrote:
>>> Am 01.10.2021 um 13:43 schrieb Öö Tiib:
>>>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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.
>>>>
>>>> What a thread does when its input queue is empty?
>>>
>>> If it hasn't anything other to do than "waiting" for a new entry it spins.
>>
>> Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic stack
>> into account. When its empty we can use, say, a futex to wait on it. This
>> would be the slow-path. A fast-path is when the stack is not empty. There is
>> a big difference between a fast and a slow path. The former is lock-free, the
>> latter might have to wait.
>>
>> This even works for wait-free structures. In this case, the fast-path would
>> be wait-free.
>
> Watch out that "wait free" isn't just spining with more cpomplex algorithm
> doing nothing usefull :P
True! Imvvvho, wait-free should be loopless. Now, I always got nervous
over trying to implement wait-free with LL/SC, an optimistic atomic
primitive. I prefer to implement them using pessimistic atomic ops like
an atomic exchange or fetch-and-add. However, then again atomic exchange
can be implemented by LL/SC, or CAS. This is not Kosher in my mind.
Quite fond of the pessimistic x86 XADD or XCHG atomic OPS when it comes
to wait-free because there is no looping involved. Actually, CAS in x86
can be used for a state machine without looping because it always
returns a result. If CAS on x86 fails we have the reason why. This is
different than LL/SC that can spuriously fail.
> here is mine mutex:
> format elf64
>
> FUTEX_WAIT equ 0
> FUTEX_WAKE equ 1
> FUTEX_PRIVATE_FLAG equ 128
>
> public futex_acquire
> public futex_release
>
> futex_acquire:
> push rbx
> push r15
> ; push r10
> mov r15,rdi
> .L0:
> mov ebx,1
> xor eax,eax
> lock cmpxchg [r15],ebx
> test eax,eax
> jz .L1
> mov eax, 202
> mov rdi, r15
> mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG
> mov edx, 1
> xor r10,r10
> syscall
> jmp .L0
> .L1:; pop r10
> pop r15
> pop rbx
> ret
>
> futex_release:
> lock and dword[rdi],0
> mov eax,202
> ; mov rdi, sema
> mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG
> mov edx,1
> syscall
> ret
Need to look at it, should work. Fwiw, here is an example using a futex
on windows. Yes it actually has one, lol! Btw, this is using XCHG only.
______________________________________
#include <iostream>
#include <thread>
#include <functional>
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#define CT_L2_ALIGNMENT 128
#define CT_THREADS 32
#define CT_ITERS 6666666
struct ct_futex_mutex
{
ULONG alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0)
{
}
void lock()
{
if (InterlockedExchange(&m_state, 1))
{
while (InterlockedExchange(&m_state, 2))
{
ULONG cmp = 2;
WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
}
}
}
void unlock()
{
if (InterlockedExchange(&m_state, 0) == 2)
{
WakeByAddressSingle(&m_state);
}
}
};
struct ct_shared
{
ct_futex_mutex m_mtx;
unsigned long m_count;
ct_shared() : m_count(0) {}
~ct_shared()
{
if (m_count != 0)
{
std::cout << "counter is totally fubar!\n";
}
}
};
void ct_thread(ct_shared& shared)
{
for (unsigned long i = 0; i < CT_ITERS; ++i)
{
shared.m_mtx.lock();
++shared.m_count;
shared.m_mtx.unlock();
shared.m_mtx.lock();
--shared.m_count;
shared.m_mtx.unlock();
}
}
int main()
{
std::thread threads[CT_THREADS];
std::cout << "Starting up...\n";
{
ct_shared shared;
for (unsigned long i = 0; i < CT_THREADS; ++i)
{
threads[i] = std::thread(ct_thread, std::ref(shared));
}
std::cout << "Running...\n";
for (unsigned long i = 0; i < CT_THREADS; ++i)
{
threads[i].join();
}
}
std::cout << "Completed!\n";
return 0;
}
______________________________________
;^)
>>
>>
>>> Lock-free and wait-free datastructures are idiocracy except from lock-free
>>> stacks.
>>
>> Sure. Whatever you say Bonita. Cough.... Cough... ;^)
> Heh, rsyncing something, looking bloat and have no patience :p
;^)
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-01 22:13 +0000 |
| Message-ID | <rKL5J.212806$T_8.27125@fx48.iad> |
| In reply to | #81722 |
On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:
>> On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> On 10/1/2021 5:59 AM, Bonita Montero wrote:
>>>> Am 01.10.2021 um 13:43 schrieb Öö Tiib:
>>>>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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.
>>>>>
>>>>> What a thread does when its input queue is empty?
>>>>
>>>> If it hasn't anything other to do than "waiting" for a new entry it spins.
>>>
>>> Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic stack
>>> into account. When its empty we can use, say, a futex to wait on it. This
>>> would be the slow-path. A fast-path is when the stack is not empty. There is
>>> a big difference between a fast and a slow path. The former is lock-free, the
>>> latter might have to wait.
>>>
>>> This even works for wait-free structures. In this case, the fast-path would
>>> be wait-free.
>>
>> Watch out that "wait free" isn't just spining with more cpomplex algorithm
>> doing nothing usefull :P
>
> True! Imvvvho, wait-free should be loopless. Now, I always got nervous
> over trying to implement wait-free with LL/SC, an optimistic atomic
> primitive. I prefer to implement them using pessimistic atomic ops like
> an atomic exchange or fetch-and-add. However, then again atomic exchange
> can be implemented by LL/SC, or CAS. This is not Kosher in my mind.
> Quite fond of the pessimistic x86 XADD or XCHG atomic OPS when it comes
> to wait-free because there is no looping involved. Actually, CAS in x86
> can be used for a state machine without looping because it always
> returns a result. If CAS on x86 fails we have the reason why. This is
> different than LL/SC that can spuriously fail.
>
>
>
>> here is mine mutex:
>> format elf64
>>
>> FUTEX_WAIT equ 0
>> FUTEX_WAKE equ 1
>> FUTEX_PRIVATE_FLAG equ 128
>>
>> public futex_acquire
>> public futex_release
>>
>> futex_acquire:
>> push rbx
>> push r15
>> ; push r10
>> mov r15,rdi
>> .L0:
>> mov ebx,1
>> xor eax,eax
>> lock cmpxchg [r15],ebx
>> test eax,eax
>> jz .L1
>> mov eax, 202
>> mov rdi, r15
>> mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG
>> mov edx, 1
>> xor r10,r10
>> syscall
>> jmp .L0
>> .L1:; pop r10
>> pop r15
>> pop rbx
>> ret
>>
>> futex_release:
>> lock and dword[rdi],0
>> mov eax,202
>> ; mov rdi, sema
>> mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG
>> mov edx,1
>> syscall
>> ret
>
> Need to look at it, should work. Fwiw, here is an example using a futex
> on windows. Yes it actually has one, lol! Btw, this is using XCHG only.
> ______________________________________
> #include <iostream>
> #include <thread>
> #include <functional>
>
> #define WIN32_LEAN_AND_MEAN
> #include <Windows.h>
>
>
> #define CT_L2_ALIGNMENT 128
> #define CT_THREADS 32
> #define CT_ITERS 6666666
>
>
> struct ct_futex_mutex
> {
> ULONG alignas(CT_L2_ALIGNMENT) m_state;
>
> ct_futex_mutex() : m_state(0)
> {
>
> }
>
> void lock()
> {
> if (InterlockedExchange(&m_state, 1))
> {
> while (InterlockedExchange(&m_state, 2))
> {
> ULONG cmp = 2;
> WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
> }
> }
> }
>
> void unlock()
> {
> if (InterlockedExchange(&m_state, 0) == 2)
> {
> WakeByAddressSingle(&m_state);
> }
> }
> };
>
>
Same thing practically, except linux futex, which is same thing.
Interrestingly Darwin does not have it and I am really interrested
how Apple immplements pthread_mutex?
--
7-77-777
Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 17:14 -0700 |
| Message-ID | <sj888o$23m$1@gioia.aioe.org> |
| In reply to | #81723 |
On 10/1/2021 3:13 PM, Branimir Maksimovic wrote:
> On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:
>>> On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>> On 10/1/2021 5:59 AM, Bonita Montero wrote:
>>>>> Am 01.10.2021 um 13:43 schrieb Öö Tiib:
>>>>>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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.
>>>>>>
>>>>>> What a thread does when its input queue is empty?
>>>>>
>>>>> If it hasn't anything other to do than "waiting" for a new entry it spins.
>>>>
>>>> Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic stack
>>>> into account. When its empty we can use, say, a futex to wait on it. This
>>>> would be the slow-path. A fast-path is when the stack is not empty. There is
>>>> a big difference between a fast and a slow path. The former is lock-free, the
>>>> latter might have to wait.
>>>>
>>>> This even works for wait-free structures. In this case, the fast-path would
>>>> be wait-free.
>>>
>>> Watch out that "wait free" isn't just spining with more cpomplex algorithm
>>> doing nothing usefull :P
>>
>> True! Imvvvho, wait-free should be loopless. Now, I always got nervous
>> over trying to implement wait-free with LL/SC, an optimistic atomic
>> primitive. I prefer to implement them using pessimistic atomic ops like
>> an atomic exchange or fetch-and-add. However, then again atomic exchange
>> can be implemented by LL/SC, or CAS. This is not Kosher in my mind.
>> Quite fond of the pessimistic x86 XADD or XCHG atomic OPS when it comes
>> to wait-free because there is no looping involved. Actually, CAS in x86
>> can be used for a state machine without looping because it always
>> returns a result. If CAS on x86 fails we have the reason why. This is
>> different than LL/SC that can spuriously fail.
>>
>>
>>
>>> here is mine mutex:
>>> format elf64
>>>
>>> FUTEX_WAIT equ 0
>>> FUTEX_WAKE equ 1
>>> FUTEX_PRIVATE_FLAG equ 128
>>>
>>> public futex_acquire
>>> public futex_release
>>>
>>> futex_acquire:
>>> push rbx
>>> push r15
>>> ; push r10
>>> mov r15,rdi
>>> .L0:
>>> mov ebx,1
>>> xor eax,eax
>>> lock cmpxchg [r15],ebx
>>> test eax,eax
>>> jz .L1
>>> mov eax, 202
>>> mov rdi, r15
>>> mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG
>>> mov edx, 1
>>> xor r10,r10
>>> syscall
>>> jmp .L0
>>> .L1:; pop r10
>>> pop r15
>>> pop rbx
>>> ret
>>>
>>> futex_release:
>>> lock and dword[rdi],0
>>> mov eax,202
>>> ; mov rdi, sema
>>> mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG
>>> mov edx,1
>>> syscall
>>> ret
>>
>> Need to look at it, should work. Fwiw, here is an example using a futex
>> on windows. Yes it actually has one, lol! Btw, this is using XCHG only.
>> ______________________________________
>> #include <iostream>
>> #include <thread>
>> #include <functional>
>>
>> #define WIN32_LEAN_AND_MEAN
>> #include <Windows.h>
>>
>>
>> #define CT_L2_ALIGNMENT 128
>> #define CT_THREADS 32
>> #define CT_ITERS 6666666
>>
>>
>> struct ct_futex_mutex
>> {
>> ULONG alignas(CT_L2_ALIGNMENT) m_state;
>>
>> ct_futex_mutex() : m_state(0)
>> {
>>
>> }
>>
>> void lock()
>> {
>> if (InterlockedExchange(&m_state, 1))
>> {
>> while (InterlockedExchange(&m_state, 2))
>> {
>> ULONG cmp = 2;
>> WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
>> }
>> }
>> }
>>
>> void unlock()
>> {
>> if (InterlockedExchange(&m_state, 0) == 2)
>> {
>> WakeByAddressSingle(&m_state);
>> }
>> }
>> };
>>
>>
> Same thing practically, except linux futex, which is same thing.
> Interrestingly Darwin does not have it and I am really interrested
> how Apple immplements pthread_mutex?
>
Ohhhh... Good question. I am not sure about Darwin. Actually, there is a
way to implement the mutex I showed you using binary semaphores for the
slow path. Iirc, it went like this, with the futex part commented out,
and the initialization of the binary sema to zero, auto-reset event on
windoze, also out:
____________________________
struct ct_futex_mutex
{
ULONG alignas(CT_L2_ALIGNMENT) m_state;
ct_futex_mutex() : m_state(0)
{
}
void lock()
{
if (InterlockedExchange(&m_state, 1))
{
while (InterlockedExchange(&m_state, 2))
{
//ULONG cmp = 2;
//WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
WaitForSingleObject(m_event, INFINITE);
}
}
}
void unlock()
{
if (InterlockedExchange(&m_state, 0) == 2)
{
//WakeByAddressSingle(&m_state);
SetEvent(m_event);
}
}
};
____________________________
That works as well. Humm...
https://github.com/apple/darwin-libpthread/blob/main/man/pthread_mutex_lock.3
https://github.com/apple/darwin-libpthread/blob/main/src/pthread_mutex.c
Need to example this! There is another way to create a nice FIFO mutex
using a fast semaphore. Iirc, it was called a benaphore:
https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 17:16 -0700 |
| Message-ID | <sj88cm$23m$2@gioia.aioe.org> |
| In reply to | #81724 |
On 10/1/2021 5:14 PM, Chris M. Thomasson wrote: > On 10/1/2021 3:13 PM, Branimir Maksimovic wrote: >> On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: [...] > There is another way to create a nice FIFO mutex > using a fast semaphore. Iirc, it was called a benaphore: > > https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26 > Basically, its adding the ability to avoid the kernel using a fast-path on the semaphore logic. Also, its wait-free on the fast-path because it can be implemented using XADD.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-02 01:44 +0000 |
| Message-ID | <cQO5J.5832$2m1.5230@fx26.iad> |
| In reply to | #81724 |
On 2021-10-02, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>> FUTEX_WAKE equ 1
>> Same thing practically, except linux futex, which is same thing.
>> Interrestingly Darwin does not have it and I am really interrested
>> how Apple immplements pthread_mutex?
>>
>
> Ohhhh... Good question. I am not sure about Darwin. Actually, there is a
> way to implement the mutex I showed you using binary semaphores for the
> slow path. Iirc, it went like this, with the futex part commented out,
> and the initialization of the binary sema to zero, auto-reset event on
> windoze, also out:
Problem is that Apple act like student newbs. They don't care about
API stability and code in general. Puring empty to void, you have
to waste time a lot if programming for macOS...
> ____________________________
> struct ct_futex_mutex
> {
> ULONG alignas(CT_L2_ALIGNMENT) m_state;
>
> ct_futex_mutex() : m_state(0)
> {
>
> }
>
> void lock()
> {
> if (InterlockedExchange(&m_state, 1))
> {
> while (InterlockedExchange(&m_state, 2))
> {
> //ULONG cmp = 2;
> //WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
>
> WaitForSingleObject(m_event, INFINITE);
> }
> }
> }
>
> void unlock()
> {
> if (InterlockedExchange(&m_state, 0) == 2)
> {
> //WakeByAddressSingle(&m_state);
>
> SetEvent(m_event);
> }
> }
> };
> ____________________________
>
> That works as well. Humm...
yeah...
>
> https://github.com/apple/darwin-libpthread/blob/main/man/pthread_mutex_lock.3
>
> https://github.com/apple/darwin-libpthread/blob/main/src/pthread_mutex.c
>
> Need to example this! There is another way to create a nice FIFO mutex
> using a fast semaphore. Iirc, it was called a benaphore:
>
> https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
I look...
--
7-77-777
Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2021-10-02 02:14 +0000 |
| Message-ID | <qgP5J.60528$2B4.7325@fx04.iad> |
| In reply to | #81724 |
On 2021-10-02, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 10/1/2021 3:13 PM, Branimir Maksimovic wrote:
>> On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:
>>>> On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>>> On 10/1/2021 5:59 AM, Bonita Montero wrote:
>>>>>> Am 01.10.2021 um 13:43 schrieb Öö Tiib:
>>>>>>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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.
>>>>>>>
>>>>>>> What a thread does when its input queue is empty?
>>>>>>
>>>>>> If it hasn't anything other to do than "waiting" for a new entry it
>>>>>> spins.
>>>>>
>>>>> Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic
>>>>> stack into account. When its empty we can use, say, a futex to wait on
>>>>> it. This would be the slow-path. A fast-path is when the stack is not
>>>>> empty. There is a big difference between a fast and a slow path. The
>>>>> former is lock-free, the latter might have to wait.
>>>>>
>>>>> This even works for wait-free structures. In this case, the fast-path
>>>>> would be wait-free.
>>>>
>>>> Watch out that "wait free" isn't just spining with more cpomplex algorithm
>>>> doing nothing usefull :P
>>>
>>> True! Imvvvho, wait-free should be loopless. Now, I always got nervous over
>>> trying to implement wait-free with LL/SC, an optimistic atomic primitive. I
>>> prefer to implement them using pessimistic atomic ops like an atomic
>>> exchange or fetch-and-add. However, then again atomic exchange can be
>>> implemented by LL/SC, or CAS. This is not Kosher in my mind. Quite fond of
>>> the pessimistic x86 XADD or XCHG atomic OPS when it comes to wait-free
>>> because there is no looping involved. Actually, CAS in x86 can be used for
>>> a state machine without looping because it always returns a result. If CAS
>>> on x86 fails we have the reason why. This is different than LL/SC that can
>>> spuriously fail.
>>>
>>>
>>>
>>>> here is mine mutex: format elf64
>>>>
>>>> FUTEX_WAIT equ 0 FUTEX_WAKE equ 1
>>>> FUTEX_PRIVATE_FLAG equ 128
>>>>
>>>> public futex_acquire public futex_release
>>>>
>>>> futex_acquire: push rbx push r15 ; push r10 mov r15,rdi .L0: mov ebx,1 xor
>>>> eax,eax lock cmpxchg [r15],ebx test eax,eax jz .L1 mov eax, 202 mov rdi,
>>>> r15 mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG mov edx, 1 xor r10,r10
>>>> syscall jmp .L0 .L1:; pop r10 pop r15 pop rbx ret
>>>>
>>>> futex_release: lock and dword[rdi],0 mov eax,202 ; mov rdi, sema
>>>> mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG mov edx,1 syscall ret
>>>
>>> Need to look at it, should work. Fwiw, here is an example using a futex on
>>> windows. Yes it actually has one, lol! Btw, this is using XCHG only.
>>> ______________________________________ #include <iostream> #include
>>> <thread> #include <functional>
>>>
>>> #define WIN32_LEAN_AND_MEAN #include <Windows.h>
>>>
>>>
>>> #define CT_L2_ALIGNMENT 128 #define CT_THREADS 32 #define CT_ITERS 6666666
>>>
>>>
>>> struct ct_futex_mutex { ULONG alignas(CT_L2_ALIGNMENT) m_state;
>>>
>>> ct_futex_mutex() : m_state(0) {
>>>
>>> }
>>>
>>> void lock() { if (InterlockedExchange(&m_state, 1)) { while
>>> (InterlockedExchange(&m_state, 2)) { ULONG cmp = 2;
>>> WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE); } } }
>>>
>>> void unlock() { if (InterlockedExchange(&m_state, 0) == 2) {
>>> WakeByAddressSingle(&m_state); } } };
>>>
>>>
>> Same thing practically, except linux futex, which is same thing.
>> Interrestingly Darwin does not have it and I am really interrested how Apple
>> immplements pthread_mutex?
>>
>
> Ohhhh... Good question. I am not sure about Darwin. Actually, there is a way
> to implement the mutex I showed you using binary semaphores for the slow
> path. Iirc, it went like this, with the futex part commented out, and the
> initialization of the binary sema to zero, auto-reset event on windoze, also
> out: ____________________________ struct ct_futex_mutex { ULONG
> alignas(CT_L2_ALIGNMENT) m_state;
>
> ct_futex_mutex() : m_state(0) {
>
> }
>
> void lock() { if (InterlockedExchange(&m_state, 1)) { while
> (InterlockedExchange(&m_state, 2)) { //ULONG cmp = 2;
> //WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
>
> WaitForSingleObject(m_event, INFINITE); } } }
>
> void unlock() { if (InterlockedExchange(&m_state, 0) == 2) {
> //WakeByAddressSingle(&m_state);
>
> SetEvent(m_event); } } }; ____________________________
>
> That works as well. Humm...
>
> https://github.com/apple/darwin-libpthread/blob/main/man/pthread_mutex_lock.3
>
> https://github.com/apple/darwin-libpthread/blob/main/src/pthread_mutex.c
>
> Need to example this! There is another way to create a nice FIFO mutex using
> a fast semaphore. Iirc, it was called a benaphore:
>
> https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
Here is Apple version:
#include <locale>
#include <iostream>
#include <thread>
#include <semaphore.h>
#include <functional>
#define CT_L2_ALIGNMENT 128
#define CT_THREADS 32
#define CT_ITERS 666666
using ULONG = unsigned long;
struct ct_futex_mutex
{
sem_t sema;
alignas(CT_L2_ALIGNMENT) ULONG m_state;
ct_futex_mutex() : m_state(0)
{
sem_init(&sema,0,0);
}
void lock()
{
if (__sync_swap(&m_state, 1))
{
while (__sync_swap(&m_state, 2))
{
sem_wait(&sema);
}
}
}
void unlock()
{
if (__sync_swap(&m_state, 0) == 2)
{
sem_post(&sema);
}
}
};
struct ct_shared
{
ct_futex_mutex m_mtx;
unsigned long m_count;
ct_shared() : m_count(0) {}
~ct_shared()
{
if (m_count != 0)
{
std::cout << "counter is totally fubar!\n";
}
}
};
void ct_thread(ct_shared& shared)
{
for (unsigned long i = 0; i < CT_ITERS; ++i)
{
shared.m_mtx.lock();
++shared.m_count;
shared.m_mtx.unlock();
shared.m_mtx.lock();
--shared.m_count;
shared.m_mtx.unlock();
}
}
int main()
{
std::locale mylocale("");
std::cout.imbue(mylocale); // use locale number formatting style
std::thread *threads = new std::thread[CT_THREADS];
std::cout << "Starting up...\n";
{
ct_shared shared;
for (unsigned long i = 0; i < CT_THREADS; ++i)
{
threads[i] = std::thread(ct_thread, std::ref(shared));
}
std::cout << "Running...\n";
for (unsigned long i = 0; i < CT_THREADS; ++i)
{
threads[i].join();
}
}
std::cout << "Completed!\n";
return 0;
}
/**
;^)
>>
>>
>>> Lock-free and wait-free datastructures are idiocracy except from lock-free
>>> stacks.
>>
>> Sure. Whatever you say Bonita. Cough.... Cough... ;^)
> Heh, rsyncing something, looking bloat and have no patience :p
;^)
*/
--
7-77-777
Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 19:33 -0700 |
| Message-ID | <sj8gei$i3p$1@gioia.aioe.org> |
| In reply to | #81732 |
On 10/1/2021 7:14 PM, Branimir Maksimovic wrote:
> On 2021-10-02, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 10/1/2021 3:13 PM, Branimir Maksimovic wrote:
>>> On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>> On 10/1/2021 1:53 PM, Branimir Maksimovic wrote:
>>>>> On 2021-10-01, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>>>> On 10/1/2021 5:59 AM, Bonita Montero wrote:
>>>>>>> Am 01.10.2021 um 13:43 schrieb Öö Tiib:
>>>>>>>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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.
>>>>>>>>
>>>>>>>> What a thread does when its input queue is empty?
>>>>>>>
>>>>>>> If it hasn't anything other to do than "waiting" for a new entry it
>>>>>>> spins.
>>>>>>
>>>>>> Huh? Ever heard of a futex, or an eventcount? Take a lock-free dynamic
>>>>>> stack into account. When its empty we can use, say, a futex to wait on
>>>>>> it. This would be the slow-path. A fast-path is when the stack is not
>>>>>> empty. There is a big difference between a fast and a slow path. The
>>>>>> former is lock-free, the latter might have to wait.
>>>>>>
>>>>>> This even works for wait-free structures. In this case, the fast-path
>>>>>> would be wait-free.
>>>>>
>>>>> Watch out that "wait free" isn't just spining with more cpomplex algorithm
>>>>> doing nothing usefull :P
>>>>
>>>> True! Imvvvho, wait-free should be loopless. Now, I always got nervous over
>>>> trying to implement wait-free with LL/SC, an optimistic atomic primitive. I
>>>> prefer to implement them using pessimistic atomic ops like an atomic
>>>> exchange or fetch-and-add. However, then again atomic exchange can be
>>>> implemented by LL/SC, or CAS. This is not Kosher in my mind. Quite fond of
>>>> the pessimistic x86 XADD or XCHG atomic OPS when it comes to wait-free
>>>> because there is no looping involved. Actually, CAS in x86 can be used for
>>>> a state machine without looping because it always returns a result. If CAS
>>>> on x86 fails we have the reason why. This is different than LL/SC that can
>>>> spuriously fail.
>>>>
>>>>
>>>>
>>>>> here is mine mutex: format elf64
>>>>>
>>>>> FUTEX_WAIT equ 0 FUTEX_WAKE equ 1
>>>>> FUTEX_PRIVATE_FLAG equ 128
>>>>>
>>>>> public futex_acquire public futex_release
>>>>>
>>>>> futex_acquire: push rbx push r15 ; push r10 mov r15,rdi .L0: mov ebx,1 xor
>>>>> eax,eax lock cmpxchg [r15],ebx test eax,eax jz .L1 mov eax, 202 mov rdi,
>>>>> r15 mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG mov edx, 1 xor r10,r10
>>>>> syscall jmp .L0 .L1:; pop r10 pop r15 pop rbx ret
>>>>>
>>>>> futex_release: lock and dword[rdi],0 mov eax,202 ; mov rdi, sema
>>>>> mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG mov edx,1 syscall ret
>>>>
>>>> Need to look at it, should work. Fwiw, here is an example using a futex on
>>>> windows. Yes it actually has one, lol! Btw, this is using XCHG only.
>>>> ______________________________________ #include <iostream> #include
>>>> <thread> #include <functional>
>>>>
>>>> #define WIN32_LEAN_AND_MEAN #include <Windows.h>
>>>>
>>>>
>>>> #define CT_L2_ALIGNMENT 128 #define CT_THREADS 32 #define CT_ITERS 6666666
>>>>
>>>>
>>>> struct ct_futex_mutex { ULONG alignas(CT_L2_ALIGNMENT) m_state;
>>>>
>>>> ct_futex_mutex() : m_state(0) {
>>>>
>>>> }
>>>>
>>>> void lock() { if (InterlockedExchange(&m_state, 1)) { while
>>>> (InterlockedExchange(&m_state, 2)) { ULONG cmp = 2;
>>>> WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE); } } }
>>>>
>>>> void unlock() { if (InterlockedExchange(&m_state, 0) == 2) {
>>>> WakeByAddressSingle(&m_state); } } };
>>>>
>>>>
>>> Same thing practically, except linux futex, which is same thing.
>>> Interrestingly Darwin does not have it and I am really interrested how Apple
>>> immplements pthread_mutex?
>>>
>>
>> Ohhhh... Good question. I am not sure about Darwin. Actually, there is a way
>> to implement the mutex I showed you using binary semaphores for the slow
>> path. Iirc, it went like this, with the futex part commented out, and the
>> initialization of the binary sema to zero, auto-reset event on windoze, also
>> out: ____________________________ struct ct_futex_mutex { ULONG
>> alignas(CT_L2_ALIGNMENT) m_state;
>>
>> ct_futex_mutex() : m_state(0) {
>>
>> }
>>
>> void lock() { if (InterlockedExchange(&m_state, 1)) { while
>> (InterlockedExchange(&m_state, 2)) { //ULONG cmp = 2;
>> //WaitOnAddress(&m_state, &cmp, sizeof(ULONG), INFINITE);
>>
>> WaitForSingleObject(m_event, INFINITE); } } }
>>
>> void unlock() { if (InterlockedExchange(&m_state, 0) == 2) {
>> //WakeByAddressSingle(&m_state);
>>
>> SetEvent(m_event); } } }; ____________________________
>>
>> That works as well. Humm...
>>
>> https://github.com/apple/darwin-libpthread/blob/main/man/pthread_mutex_lock.3
>>
>> https://github.com/apple/darwin-libpthread/blob/main/src/pthread_mutex.c
>>
>> Need to example this! There is another way to create a nice FIFO mutex using
>> a fast semaphore. Iirc, it was called a benaphore:
>>
>> https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
> Here is Apple version:
[...]
Excellent! That is basically identical to the bin-sema version! For what
its worth, take reference to a man by the name of Alexander Terekhov!
And look at the code in pthreads-win32 sources. I used to converse with
this genius way back on comp.programming.threads. He was a pleasure to
talk to. Actually, I am SenderX way back here:
https://groups.google.com/g/comp.programming.threads/c/KepRbFWBJA4/m/pg83oJTzPUIJ
;^)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-02 06:39 +0200 |
| Message-ID | <sj8nqf$q2j$1@dont-email.me> |
| In reply to | #81715 |
Am 01.10.2021 um 22:04 schrieb Chris M. Thomasson: > On 10/1/2021 5:59 AM, Bonita Montero wrote: >> Am 01.10.2021 um 13:43 schrieb Öö Tiib: >>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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. >>> >>> What a thread does when its input queue is empty? >> >> If it hasn't anything other to do than "waiting" for a new entry it >> spins. > > Huh? Ever heard of a futex, or an eventcount? Lock-free is without any kernel-structures and polling only. No futex.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 22:12 -0700 |
| Message-ID | <sj8pnp$v0b$1@gioia.aioe.org> |
| In reply to | #81735 |
On 10/1/2021 9:39 PM, Bonita Montero wrote: > Am 01.10.2021 um 22:04 schrieb Chris M. Thomasson: >> On 10/1/2021 5:59 AM, Bonita Montero wrote: >>> Am 01.10.2021 um 13:43 schrieb Öö Tiib: >>>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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. >>>> >>>> What a thread does when its input queue is empty? >>> >>> If it hasn't anything other to do than "waiting" for a new entry it >>> spins. >> >> Huh? Ever heard of a futex, or an eventcount? > > Lock-free is without any kernel-structures and polling only. > No futex. Lock-free on the fast-path... Ever heard of such a thing? Wow.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-10-02 07:35 +0200 |
| Message-ID | <sj8r37$ans$1@dont-email.me> |
| In reply to | #81738 |
Am 02.10.2021 um 07:12 schrieb Chris M. Thomasson: > On 10/1/2021 9:39 PM, Bonita Montero wrote: >> Am 01.10.2021 um 22:04 schrieb Chris M. Thomasson: >>> On 10/1/2021 5:59 AM, Bonita Montero wrote: >>>> Am 01.10.2021 um 13:43 schrieb Öö Tiib: >>>>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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. >>>>> >>>>> What a thread does when its input queue is empty? >>>> >>>> If it hasn't anything other to do than "waiting" for a new entry it >>>> spins. >>> >>> Huh? Ever heard of a futex, or an eventcount? >> >> Lock-free is without any kernel-structures and polling only. >> No futex. > > Lock-free on the fast-path... Ever heard of such a thing? Wow. There is no slow path with lock-free structures.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-01 22:49 -0700 |
| Message-ID | <sj8rt9$1ivh$1@gioia.aioe.org> |
| In reply to | #81742 |
On 10/1/2021 10:35 PM, Bonita Montero wrote: > Am 02.10.2021 um 07:12 schrieb Chris M. Thomasson: >> On 10/1/2021 9:39 PM, Bonita Montero wrote: >>> Am 01.10.2021 um 22:04 schrieb Chris M. Thomasson: >>>> On 10/1/2021 5:59 AM, Bonita Montero wrote: >>>>> Am 01.10.2021 um 13:43 schrieb Öö Tiib: >>>>>> On Friday, 1 October 2021 at 04:32:18 UTC+3, Bonita Montero 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. >>>>>> >>>>>> What a thread does when its input queue is empty? >>>>> >>>>> If it hasn't anything other to do than "waiting" for a new entry it >>>>> spins. >>>> >>>> Huh? Ever heard of a futex, or an eventcount? >>> >>> Lock-free is without any kernel-structures and polling only. >>> No futex. >> >> Lock-free on the fast-path... Ever heard of such a thing? Wow. > > There is no slow path with lock-free structures. Ummmm... You are just trolling me right? A slow path would be what to do when one needs to wait, on say, an empty condition? Humm... Why do you troll?
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c++
csiph-web