Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #157279 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2020-12-15 13:57 -0800 |
| Last post | 2020-12-21 22:17 +0100 |
| Articles | 20 on this page of 300 — 18 participants |
Back to article view | Back to comp.lang.c
A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-15 13:57 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-16 02:11 +0300
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 01:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 10:48 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 04:16 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:04 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 16:06 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 15:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 19:32 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 21:12 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-17 13:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:35 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 06:05 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 15:28 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 08:49 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 18:24 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 10:31 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 16:53 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:33 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:06 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:55 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:09 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-18 15:39 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:55 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 17:05 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 17:12 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:41 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 10:13 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:28 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 11:35 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:45 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 13:26 -0500
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 11:31 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 20:41 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 19:57 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:05 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 20:26 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:59 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 15:23 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 17:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:21 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 20:13 +0000
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:37 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 16:26 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-25 00:55 +0000
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 12:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 14:01 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 16:32 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 07:42 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 16:07 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:38 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 17:25 +0100
Re: A defer mechanism for C Christian Hanné <the.hanne@gmail.com> - 2020-12-20 17:46 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 09:07 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:43 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 10:11 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 14:58 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:58 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:41 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 20:25 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 22:34 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 20:52 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-20 12:37 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:42 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:19 -0500
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-21 10:18 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 11:06 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:09 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:13 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:18 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:26 -0700
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:47 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:59 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:25 -0700
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-21 14:23 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-22 09:58 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:57 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:19 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-27 11:24 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 22:45 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 00:33 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 11:31 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-29 17:24 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 18:43 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 11:32 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 03:34 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 21:06 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-29 20:40 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 02:56 -0800
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:22 -0700
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 02:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 06:49 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-24 03:16 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 13:38 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:37 -0800
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-25 11:39 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:34 -0800
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:48 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-27 08:51 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 22:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 09:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:18 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:32 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:55 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:16 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 22:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:42 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 05:53 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:40 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 05:19 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 11:01 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 03:45 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 13:25 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 06:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 15:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 07:05 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:13 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:21 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:06 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 08:57 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:43 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-16 12:05 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 14:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 15:57 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:49 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 11:33 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:05 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:52 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 10:59 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 20:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 19:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 21:56 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:03 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 12:30 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:16 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:39 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 13:44 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 06:54 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 13:28 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:14 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:16 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:19 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:26 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 17:07 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 18:18 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 18:34 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:40 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 21:16 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 22:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 21:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:25 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:01 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 02:45 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 13:33 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:24 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:28 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 21:55 -0800
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:38 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:51 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-25 20:00 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:19 +0100
Re: A defer mechanism for C Öö Tiib <ootiib@hot.ee> - 2020-12-26 19:10 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 05:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:42 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 02:29 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:11 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 09:33 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 18:50 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-26 07:40 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:36 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:49 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:39 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:25 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 01:55 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:16 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:55 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:10 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 16:47 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:22 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:09 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:25 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 08:02 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:55 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 21:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 23:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:40 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:59 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:10 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:46 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:46 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:00 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 10:59 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 11:12 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:18 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 16:25 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 19:24 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 09:07 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:36 +0300
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-19 15:54 -0500
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 01:21 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 15:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:53 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:55 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 12:07 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 03:38 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:40 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:00 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:02 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:43 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:34 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:11 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 17:22 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:08 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:26 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:36 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:54 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:12 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 15:13 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 12:45 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 16:25 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 13:38 +0000
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:26 -0500
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 20:30 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 21:41 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:14 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:25 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:38 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:44 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:07 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 00:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:51 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 06:15 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 06:25 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:43 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:55 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:52 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 00:40 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:46 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:22 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:31 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 22:27 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 09:36 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-21 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:24 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:07 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-16 18:35 -0800
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 04:08 +0000
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 23:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 20:29 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:26 +0300
Re: A defer mechanism for C fir <profesor.fir@gmail.com> - 2020-12-21 05:02 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 15:03 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 06:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 16:51 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:17 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:22 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:46 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:04 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 10:57 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:10 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 11:39 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:48 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:34 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:15 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:26 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:45 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 20:15 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:28 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 20:49 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:17 +0100
Page 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 20:45 +0100 |
| Message-ID | <rrj0sl$lbo$3@dont-email.me> |
| In reply to | #157411 |
>> The thread would gain its computation-time only by polling every >> time-slice. And you would have to check the acquired-flag while >> disabling the interrupt because it could asynchronously been set. > It yields if the flag is set. ... You must check it while having disabled the interrupts because it could be set by another thread !
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-18 11:55 -0800 |
| Message-ID | <e162c790-2374-42ed-916b-504b0bf0dbb6n@googlegroups.com> |
| In reply to | #157417 |
On Friday, 18 December 2020 at 19:45:40 UTC, Bonita Montero wrote: > >> The thread would gain its computation-time only by polling every > >> time-slice. And you would have to check the acquired-flag while > >> disabling the interrupt because it could asynchronously been set. > > It yields if the flag is set. ... > > You must check it while having disabled the interrupts because > it could be set by another thread ! > Fair enough. It's unlikely that read / branch is atomic if write is not.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 21:08 +0100 |
| Message-ID | <rrj28i$1vj$1@dont-email.me> |
| In reply to | #157418 |
Am 18.12.2020 um 20:55 schrieb Malcolm McLean:
> On Friday, 18 December 2020 at 19:45:40 UTC, Bonita Montero wrote:
>>>> The thread would gain its computation-time only by polling every
>>>> time-slice. And you would have to check the acquired-flag while
>>>> disabling the interrupt because it could asynchronously been set.
>>> It yields if the flag is set. ...
>>
>> You must check it while having disabled the interrupts because
>> it could be set by another thread !
>>
> Fair enough. It's unlikely that read / branch is atomic if write is not.
>
Look at this
Mutex()
{
while (acquired)
yield();
<- at this pint acquired could have been set
disable_interrupts();
acquired = true;
enable_interrupts();
}
The code should look like this:
Mutex()
{
for( ; ; )
{
disable_interrupts();
if( acquired )
break;
enable_interrupts();
yield();
}
acquired = true;
enable_interrupts();
}
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 21:09 +0100 |
| Message-ID | <rrj29j$1vj$2@dont-email.me> |
| In reply to | #157419 |
Am 18.12.2020 um 21:08 schrieb Bonita Montero:
> Am 18.12.2020 um 20:55 schrieb Malcolm McLean:
>> On Friday, 18 December 2020 at 19:45:40 UTC, Bonita Montero wrote:
>>>>> The thread would gain its computation-time only by polling every
>>>>> time-slice. And you would have to check the acquired-flag while
>>>>> disabling the interrupt because it could asynchronously been set.
>>>> It yields if the flag is set. ...
>>>
>>> You must check it while having disabled the interrupts because
>>> it could be set by another thread !
>>>
>> Fair enough. It's unlikely that read / branch is atomic if write is not.
>>
>
> Look at this
>
> Mutex()
> {
> while (acquired)
> yield();
> <- at this pint acquired could have been set
> disable_interrupts();
> acquired = true;
> enable_interrupts();
> }
>
> The code should look like this:
>
> Mutex()
> {
> for( ; ; )
> {
> disable_interrupts();
> if( acquired )
if( !acquired ) // sorry> break;
> enable_interrupts();
> yield();
>
> }
> acquired = true;
> enable_interrupts();
> }
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-18 15:39 -0500 |
| Message-ID | <Sr8DH.16700$192.3995@fx47.iad> |
| In reply to | #157399 |
On 12/18/20 11:49 AM, Malcolm McLean wrote:
> The code would be something like
>
> class Mutex
> {
> static bool aquired = false;
>
> Mutex()
> {
> while (acquired)
> yield();
> disable_interrupts();
> acquired = true;
> enable_interrupts();
> }
> ~Mutex()
> {
> disable_interrupts();
> acquired = false;
> enable_interrupts();
> }
> }
>
Looking at this code, my biggest concern is this seems to have a race
between the checking that the mutex isn't held by anyone else, and the
claiming of it.
The bracketing of the setting of the acquired flag imlplies that there
is a concern about these sort of races, but the setting of the bool may
well be atomic and not need protection around it, there should be
something similar protecting the test in the while and the setting.
Maybe a first cut would be something like:
Mutex()
{
disable_interrupts();
while (acquired)
{
enable_interrupts();
yield();
disable_interrupts();
}
acquired = true;
enable_interrupts();
}
This keeps the interrupts disabled between the test and the claim, but
have them enabled for the yield().
Note, this does NOT work on a multi-core processor, but that is clear
from the use if interrupt control for inner critical sections.
The other big issue, that has been pointed out is that normally you
build a system with multiple mutexes, and a lock method that locks that
particular mutex.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 21:55 +0100 |
| Message-ID | <rrj4vb$k20$1@dont-email.me> |
| In reply to | #157421 |
> Note, this does NOT work on a multi-core processor, ... If disabling the interrupts is global this should work. > The other big issue, that has been pointed out is that normally you > build a system with multiple mutexes, and a lock method that locks > that particular mutex. Not every operating-system has the ability to wait on multiple events at the same time like with SysV-semaphores or Windows' WaitForXxx.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-19 17:05 +0100 |
| Message-ID | <rrl8ci$1kb$1@dont-email.me> |
| In reply to | #157421 |
On 18/12/2020 21:39, Richard Damon wrote:
> On 12/18/20 11:49 AM, Malcolm McLean wrote:
>> The code would be something like
>>
>> class Mutex
>> {
>> static bool aquired = false;
>>
>> Mutex()
>> {
>> while (acquired)
>> yield();
>> disable_interrupts();
>> acquired = true;
>> enable_interrupts();
>> }
>> ~Mutex()
>> {
>> disable_interrupts();
>> acquired = false;
>> enable_interrupts();
>> }
>> }
>>
>
> Looking at this code, my biggest concern is this seems to have a race
> between the checking that the mutex isn't held by anyone else, and the
> claiming of it.
>
That is certainly an issue - but it is not the biggest problem. Nor is
the fact that it won't work on a multi-core system (since disabling
interrupts does not affect other cores).
What do you think will happen on a "yield()" ?
(I'm assuming that "yield()" is supposed to do what yield functions
normally do. This is Malcolm's code, however, and along with
Malcolm-mutexes we could be talking about Malcolm-yield, and
Malcolm-interrupts, to extend the existing vocabulary of
Malcolm-functions, Malcolm-arrays, and other Malcolm specific terminology.)
On a "yield()", if there is another thread of the same priority in the
runable state, the current thread will be paused and the new one will
start. If that's the thread that currently holds the mutex, all is well
and good. (Baring the race condition.)
But if the thread that holds the mutex is a lower priority, it will not
be scheduled after the yield() - even if it is runable. The current
thread will simply continue to run, in a tight loop, waiting for the
acquired flag to be released. Deadlock.
Mutexes must be implemented as part of the operating system, in
cooperation with the scheduler. (Or they can be implemented on top of
other primitives that are part of the OS, such as queues.) You can't
make them like Malcolm is trying to do here - even if you are talking
about a single global lock rather than mutexes.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-19 17:12 +0100 |
| Message-ID | <rrl8pl$427$1@dont-email.me> |
| In reply to | #157472 |
> But if the thread that holds the mutex is a lower priority, it > will not be scheduled after the yield() - even if it is runable. ... It will run for a time-slice.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-19 18:41 +0100 |
| Message-ID | <rrldve$bim$1@dont-email.me> |
| In reply to | #157473 |
On 19/12/2020 17:12, Bonita Montero wrote: >> But if the thread that holds the mutex is a lower priority, it >> will not be scheduled after the yield() - even if it is runable. ... > > It will run for a time-slice. Most OS's run the highest priority runable thread at any given time. On general-purpose OS's (Linux, Windows, etc.), the majority of threads are the same priority, and typically only a few kernel threads have higher priority. In embedded OS's - the kind of system where disabling interrupts is possible and likely - systems usually have threads at many different priorities. And only the highest priority runable thread ever runs.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-19 10:13 -0800 |
| Message-ID | <9f462411-fba8-4a10-b43e-85bb1a04209fn@googlegroups.com> |
| In reply to | #157473 |
On Saturday, 19 December 2020 at 16:12:54 UTC, Bonita Montero wrote: > > But if the thread that holds the mutex is a lower priority, it > > will not be scheduled after the yield() - even if it is runable. ... > > It will run for a time-slice. > If the thread hogs the processor until it yields, then immediately gets it back after the process that takes it up yields, then you can only have two threads runnable at any one time. Some system may work like that. In video games you need basically the audio thread running a high priority and the video thread running at a lower priority. However the system I actually used allowed for multiple threads. I can't remember the details of priority and scheduling, though you definitely yilded if you had finished processing and awaited more data.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 13:28 +0100 |
| Message-ID | <rrng19$c0b$1@dont-email.me> |
| In reply to | #157483 |
On 19/12/2020 19:13, Malcolm McLean wrote: > On Saturday, 19 December 2020 at 16:12:54 UTC, Bonita Montero wrote: >>> But if the thread that holds the mutex is a lower priority, it >>> will not be scheduled after the yield() - even if it is runable. ... >> >> It will run for a time-slice. >> > If the thread hogs the processor until it yields, then immediately gets > it back after the process that takes it up yields, then you can only have > two threads runnable at any one time. > The normal setup is that when you have multiple runable (unblocked) threads or processes of the same priority, they are scheduled as round-robin. When once thread yields, or its time-slice runs out (for time-shared systems), then next on the list is run. It doesn't get a chance again until you have gone round the whole list. > Some system may work like that. In video games you need basically the > audio thread running a high priority and the video thread running at a > lower priority. However the system I actually used allowed for multiple > threads. I can't remember the details of priority and scheduling, though you > definitely yilded if you had finished processing and awaited more data. >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-19 11:35 -0500 |
| Message-ID | <EZpDH.6732$rY1.2309@fx40.iad> |
| In reply to | #157472 |
On 12/19/20 11:05 AM, David Brown wrote:
> On 18/12/2020 21:39, Richard Damon wrote:
>> On 12/18/20 11:49 AM, Malcolm McLean wrote:
>>> The code would be something like
>>>
>>> class Mutex
>>> {
>>> static bool aquired = false;
>>>
>>> Mutex()
>>> {
>>> while (acquired)
>>> yield();
>>> disable_interrupts();
>>> acquired = true;
>>> enable_interrupts();
>>> }
>>> ~Mutex()
>>> {
>>> disable_interrupts();
>>> acquired = false;
>>> enable_interrupts();
>>> }
>>> }
>>>
>>
>> Looking at this code, my biggest concern is this seems to have a race
>> between the checking that the mutex isn't held by anyone else, and the
>> claiming of it.
>>
>
> That is certainly an issue - but it is not the biggest problem. Nor is
> the fact that it won't work on a multi-core system (since disabling
> interrupts does not affect other cores).
>
> What do you think will happen on a "yield()" ?
>
> (I'm assuming that "yield()" is supposed to do what yield functions
> normally do. This is Malcolm's code, however, and along with
> Malcolm-mutexes we could be talking about Malcolm-yield, and
> Malcolm-interrupts, to extend the existing vocabulary of
> Malcolm-functions, Malcolm-arrays, and other Malcolm specific terminology.)
>
> On a "yield()", if there is another thread of the same priority in the
> runable state, the current thread will be paused and the new one will
> start. If that's the thread that currently holds the mutex, all is well
> and good. (Baring the race condition.)
>
> But if the thread that holds the mutex is a lower priority, it will not
> be scheduled after the yield() - even if it is runable. The current
> thread will simply continue to run, in a tight loop, waiting for the
> acquired flag to be released. Deadlock.
>
> Mutexes must be implemented as part of the operating system, in
> cooperation with the scheduler. (Or they can be implemented on top of
> other primitives that are part of the OS, such as queues.) You can't
> make them like Malcolm is trying to do here - even if you are talking
> about a single global lock rather than mutexes.
>
>
Yes, it requries that the call to yield is enough to give time to the
thread that currently holds the mutex. It might well be that is system
has just a single priority of tasks.
Mutexes don't HAVE to be implemented in the OS, but can work better if
they are.
A good OS will have some way to tell the scheduler not to give you time
until some condition happens to avoid all the wasteful time that is
spent for everyone checking if the mutex is free every chance they get.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-19 18:45 +0100 |
| Message-ID | <rrle7l$di5$1@dont-email.me> |
| In reply to | #157475 |
On 19/12/2020 17:35, Richard Damon wrote:
> On 12/19/20 11:05 AM, David Brown wrote:
>> On 18/12/2020 21:39, Richard Damon wrote:
>>> On 12/18/20 11:49 AM, Malcolm McLean wrote:
>>>> The code would be something like
>>>>
>>>> class Mutex
>>>> {
>>>> static bool aquired = false;
>>>>
>>>> Mutex()
>>>> {
>>>> while (acquired)
>>>> yield();
>>>> disable_interrupts();
>>>> acquired = true;
>>>> enable_interrupts();
>>>> }
>>>> ~Mutex()
>>>> {
>>>> disable_interrupts();
>>>> acquired = false;
>>>> enable_interrupts();
>>>> }
>>>> }
>>>>
>>>
>>> Looking at this code, my biggest concern is this seems to have a race
>>> between the checking that the mutex isn't held by anyone else, and the
>>> claiming of it.
>>>
>>
>> That is certainly an issue - but it is not the biggest problem. Nor is
>> the fact that it won't work on a multi-core system (since disabling
>> interrupts does not affect other cores).
>>
>> What do you think will happen on a "yield()" ?
>>
>> (I'm assuming that "yield()" is supposed to do what yield functions
>> normally do. This is Malcolm's code, however, and along with
>> Malcolm-mutexes we could be talking about Malcolm-yield, and
>> Malcolm-interrupts, to extend the existing vocabulary of
>> Malcolm-functions, Malcolm-arrays, and other Malcolm specific terminology.)
>>
>> On a "yield()", if there is another thread of the same priority in the
>> runable state, the current thread will be paused and the new one will
>> start. If that's the thread that currently holds the mutex, all is well
>> and good. (Baring the race condition.)
>>
>> But if the thread that holds the mutex is a lower priority, it will not
>> be scheduled after the yield() - even if it is runable. The current
>> thread will simply continue to run, in a tight loop, waiting for the
>> acquired flag to be released. Deadlock.
>>
>> Mutexes must be implemented as part of the operating system, in
>> cooperation with the scheduler. (Or they can be implemented on top of
>> other primitives that are part of the OS, such as queues.) You can't
>> make them like Malcolm is trying to do here - even if you are talking
>> about a single global lock rather than mutexes.
>>
>>
> Yes, it requries that the call to yield is enough to give time to the
> thread that currently holds the mutex. It might well be that is system
> has just a single priority of tasks.
>
> Mutexes don't HAVE to be implemented in the OS, but can work better if
> they are.
>
They have to be implemented to suit the OS, at the very least. As I
said, his "mutex" would sort-of work in a system with one core and one
thread priority. Such systems might exist, but they'd be rare.
Embedded systems (and I assume he is thinking of an embedded system,
where user code can enable or disable interrupts) are generally either
"bare metal" (no OS, no threads, no mutexes) or use RTOS's with multiple
priorities.
> A good OS will have some way to tell the scheduler not to give you time
> until some condition happens to avoid all the wasteful time that is
> spent for everyone checking if the mutex is free every chance they get.
>
Of course. You do that using blocking system calls (like "wait for
mutex"). yield() is not a blocking system call.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-19 13:26 -0500 |
| Message-ID | <GBrDH.17132$_j2.17027@fx26.iad> |
| In reply to | #157481 |
On 12/19/20 12:45 PM, David Brown wrote:
> On 19/12/2020 17:35, Richard Damon wrote:
>> On 12/19/20 11:05 AM, David Brown wrote:
>>> On 18/12/2020 21:39, Richard Damon wrote:
>>>> On 12/18/20 11:49 AM, Malcolm McLean wrote:
>>>>> The code would be something like
>>>>>
>>>>> class Mutex
>>>>> {
>>>>> static bool aquired = false;
>>>>>
>>>>> Mutex()
>>>>> {
>>>>> while (acquired)
>>>>> yield();
>>>>> disable_interrupts();
>>>>> acquired = true;
>>>>> enable_interrupts();
>>>>> }
>>>>> ~Mutex()
>>>>> {
>>>>> disable_interrupts();
>>>>> acquired = false;
>>>>> enable_interrupts();
>>>>> }
>>>>> }
>>>>>
>>>>
>>>> Looking at this code, my biggest concern is this seems to have a race
>>>> between the checking that the mutex isn't held by anyone else, and the
>>>> claiming of it.
>>>>
>>>
>>> That is certainly an issue - but it is not the biggest problem. Nor is
>>> the fact that it won't work on a multi-core system (since disabling
>>> interrupts does not affect other cores).
>>>
>>> What do you think will happen on a "yield()" ?
>>>
>>> (I'm assuming that "yield()" is supposed to do what yield functions
>>> normally do. This is Malcolm's code, however, and along with
>>> Malcolm-mutexes we could be talking about Malcolm-yield, and
>>> Malcolm-interrupts, to extend the existing vocabulary of
>>> Malcolm-functions, Malcolm-arrays, and other Malcolm specific terminology.)
>>>
>>> On a "yield()", if there is another thread of the same priority in the
>>> runable state, the current thread will be paused and the new one will
>>> start. If that's the thread that currently holds the mutex, all is well
>>> and good. (Baring the race condition.)
>>>
>>> But if the thread that holds the mutex is a lower priority, it will not
>>> be scheduled after the yield() - even if it is runable. The current
>>> thread will simply continue to run, in a tight loop, waiting for the
>>> acquired flag to be released. Deadlock.
>>>
>>> Mutexes must be implemented as part of the operating system, in
>>> cooperation with the scheduler. (Or they can be implemented on top of
>>> other primitives that are part of the OS, such as queues.) You can't
>>> make them like Malcolm is trying to do here - even if you are talking
>>> about a single global lock rather than mutexes.
>>>
>>>
>> Yes, it requries that the call to yield is enough to give time to the
>> thread that currently holds the mutex. It might well be that is system
>> has just a single priority of tasks.
>>
>> Mutexes don't HAVE to be implemented in the OS, but can work better if
>> they are.
>>
>
> They have to be implemented to suit the OS, at the very least. As I
> said, his "mutex" would sort-of work in a system with one core and one
> thread priority. Such systems might exist, but they'd be rare.
> Embedded systems (and I assume he is thinking of an embedded system,
> where user code can enable or disable interrupts) are generally either
> "bare metal" (no OS, no threads, no mutexes) or use RTOS's with multiple
> priorities.
My first guess is this is a very bear bones os, that may not have task
priorities levels, possibly something home grown. A 'real' micro real
time os would have had the mutex defined, so he wouldn't have needed to
do it.
With Malcome, sometimes you need to back figure what the environment he
is probalby using, and not just assume it is something 'normal'.
>
>> A good OS will have some way to tell the scheduler not to give you time
>> until some condition happens to avoid all the wasteful time that is
>> spent for everyone checking if the mutex is free every chance they get.
>>
>
> Of course. You do that using blocking system calls (like "wait for
> mutex"). yield() is not a blocking system call.
>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-19 11:31 -0800 |
| Message-ID | <81f236a7-76cc-499d-91c1-aff76ea471c2n@googlegroups.com> |
| In reply to | #157484 |
On Saturday, 19 December 2020 at 18:27:03 UTC, Richard Damon wrote:
> On 12/19/20 12:45 PM, David Brown wrote:
> > On 19/12/2020 17:35, Richard Damon wrote:
> >> On 12/19/20 11:05 AM, David Brown wrote:
> >>> On 18/12/2020 21:39, Richard Damon wrote:
> >>>> On 12/18/20 11:49 AM, Malcolm McLean wrote:
> >>>>> The code would be something like
> >>>>>
> >>>>> class Mutex
> >>>>> {
> >>>>> static bool aquired = false;
> >>>>>
> >>>>> Mutex()
> >>>>> {
> >>>>> while (acquired)
> >>>>> yield();
> >>>>> disable_interrupts();
> >>>>> acquired = true;
> >>>>> enable_interrupts();
> >>>>> }
> >>>>> ~Mutex()
> >>>>> {
> >>>>> disable_interrupts();
> >>>>> acquired = false;
> >>>>> enable_interrupts();
> >>>>> }
> >>>>> }
> >>>>>
> >>>>
> >>>> Looking at this code, my biggest concern is this seems to have a race
> >>>> between the checking that the mutex isn't held by anyone else, and the
> >>>> claiming of it.
> >>>>
> >>>
> >>> That is certainly an issue - but it is not the biggest problem. Nor is
> >>> the fact that it won't work on a multi-core system (since disabling
> >>> interrupts does not affect other cores).
> >>>
> >>> What do you think will happen on a "yield()" ?
> >>>
> >>> (I'm assuming that "yield()" is supposed to do what yield functions
> >>> normally do. This is Malcolm's code, however, and along with
> >>> Malcolm-mutexes we could be talking about Malcolm-yield, and
> >>> Malcolm-interrupts, to extend the existing vocabulary of
> >>> Malcolm-functions, Malcolm-arrays, and other Malcolm specific terminology.)
> >>>
> >>> On a "yield()", if there is another thread of the same priority in the
> >>> runable state, the current thread will be paused and the new one will
> >>> start. If that's the thread that currently holds the mutex, all is well
> >>> and good. (Baring the race condition.)
> >>>
> >>> But if the thread that holds the mutex is a lower priority, it will not
> >>> be scheduled after the yield() - even if it is runable. The current
> >>> thread will simply continue to run, in a tight loop, waiting for the
> >>> acquired flag to be released. Deadlock.
> >>>
> >>> Mutexes must be implemented as part of the operating system, in
> >>> cooperation with the scheduler. (Or they can be implemented on top of
> >>> other primitives that are part of the OS, such as queues.) You can't
> >>> make them like Malcolm is trying to do here - even if you are talking
> >>> about a single global lock rather than mutexes.
> >>>
> >>>
> >> Yes, it requries that the call to yield is enough to give time to the
> >> thread that currently holds the mutex. It might well be that is system
> >> has just a single priority of tasks.
> >>
> >> Mutexes don't HAVE to be implemented in the OS, but can work better if
> >> they are.
> >>
> >
> > They have to be implemented to suit the OS, at the very least. As I
> > said, his "mutex" would sort-of work in a system with one core and one
> > thread priority. Such systems might exist, but they'd be rare.
> > Embedded systems (and I assume he is thinking of an embedded system,
> > where user code can enable or disable interrupts) are generally either
> > "bare metal" (no OS, no threads, no mutexes) or use RTOS's with multiple
> > priorities.
> My first guess is this is a very bear bones os, that may not have task
> priorities levels, possibly something home grown. A 'real' micro real
> time os would have had the mutex defined, so he wouldn't have needed to
> do it.
>
> With Malcome, sometimes you need to back figure what the environment he
> is probalby using, and not just assume it is something 'normal'.
>
I implemented malloc() and a colleague implemented trig functions for it,
so yes, it was pretty bare bones. However I think threads were built in. I
definitely remember that the audio thread had a higher priority than the video
thread, because I did the audio programming.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-19 20:41 +0100 |
| Message-ID | <rrll1h$t1b$2@dont-email.me> |
| In reply to | #157487 |
> I implemented malloc() and a colleague implemented trig functions for it, > so yes, it was pretty bare bones. ... Don't implement malloc() yourself, there are others which have done a lot of research on that and which did it better. There are extremly fast malloc()-implementations like mimalloc from Microsoft Relsearch which is currently the fastest implementation.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-19 19:57 +0000 |
| Message-ID | <xWsDH.161578$Cp69.59447@fx19.ams4> |
| In reply to | #157489 |
On 19/12/2020 19:41, Bonita Montero wrote:
>> I implemented malloc() and a colleague implemented trig functions for it,
>> so yes, it was pretty bare bones. ...
>
> Don't implement malloc() yourself, there are others which have done
> a lot of research on that and which did it better. There are extremly
> fast malloc()-implementations like mimalloc from Microsoft Relsearch
> which is currently the fastest implementation.
If I run the binary trees benchmark:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html
then a version using normal malloc/free, compiled with gcc-O3, runs at
half the speed of my version using my own allocator.
I don't know what malloc version gcc on Windows happens to use, but for
this purpose, mine is faster.
(Mine is a small-object allocator implemented on top of larger memory
blocks obtained with any other allocator including malloc. It doesn't
need to store the block size, which helps.)
----------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
int nallocs;
typedef struct _node {
struct _node *left;
struct _node *right;
int item;
} treenode;
treenode* newtreenode(treenode* left, treenode* right, int item) {
treenode* t;
t=malloc(sizeof(treenode));
++nallocs;
t->left=left;
t->right=right;
t->item=item;
return t;
}
int itemcheck(treenode* tree) {
if (tree->left==NULL)
return tree->item;
else
return tree->item+itemcheck(tree->left)-itemcheck(tree->right);
}
treenode* bottomuptree(int item, int depth) {
if (depth>0)
return newtreenode(bottomuptree(2*item-1,depth-1),
bottomuptree(2*item,depth-1),item);
else
return newtreenode(NULL,NULL,item);
}
void deletetree(treenode* tree) {
if (tree->left) {
deletetree(tree->left);
deletetree(tree->right);
}
free(tree);
}
int main(void) {
treenode *stretchtree, *longlivedtree, *temptree;
int n,depth,mindepth,maxdepth,stretchdepth,check,iterations,i;
n=16;
mindepth=4;
if ((mindepth+2)>n)
maxdepth=mindepth+1;
else
maxdepth=n;
stretchdepth=maxdepth+1;
stretchtree=bottomuptree(0,stretchdepth);
printf("Stretch tree of depth %d check: %d\n",
stretchdepth,itemcheck(stretchtree));
deletetree(stretchtree);
longlivedtree=bottomuptree(0,maxdepth);
depth=mindepth;
while (depth<=maxdepth) {
iterations=1<<(maxdepth-depth+mindepth);
check=0;
for (i=1; i<=iterations; ++i) {
temptree=bottomuptree(i,depth);
check=check+itemcheck(temptree);
deletetree(temptree);
temptree=bottomuptree(-i,depth);
check=check+itemcheck(temptree);
deletetree(temptree);
}
printf("%d Trees of depth %d check: %d\n", iterations*2,
depth, check);
depth=depth+2;
}
printf("%s %d %s %d\n", "long lived tree of depth", maxdepth,
"\tcheck:",itemcheck(longlivedtree));
printf("Mallocs = %d\n",nallocs);
}
----------------------------------------------------
(gcc-O3 takes 3.8 seconds. My language's version, same algorithm, but
malloc/free replaced by my versions, takes 1.8 seconds.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-19 21:05 +0100 |
| Message-ID | <rrlmf3$7vd$1@dont-email.me> |
| In reply to | #157490 |
> If I run the binary trees benchmark: > https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html > then a version using normal malloc/free, compiled with gcc-O3, runs at > half the speed of my version using my own allocator. I'll bet my right hand that you're too stupid to write an universal memory-allocator which really performs.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-19 20:26 +0000 |
| Message-ID | <WltDH.464876$lp01.279855@fx08.ams4> |
| In reply to | #157491 |
On 19/12/2020 20:05, Bonita Montero wrote: >> If I run the binary trees benchmark: >> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html >> then a version using normal malloc/free, compiled with gcc-O3, runs at >> half the speed of my version using my own allocator. > > I'll bet my right hand that you're too stupid to write an universal > memory-allocator which really performs. When I started programming 'for real' I had to write nearly everything for the applications running in my computer, because the OS only provided a file system and a text display, on machines which had 1/10000th the memory of today's PCs. That including writing memory allocators for that very restricted memory. And guess what, they worked fine. But go on, have the last word.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 13:59 +0100 |
| Message-ID | <rrnhrd$p1k$1@dont-email.me> |
| In reply to | #157490 |
On 19/12/2020 20:57, Bart wrote: > On 19/12/2020 19:41, Bonita Montero wrote: >>> I implemented malloc() and a colleague implemented trig functions for >>> it, >>> so yes, it was pretty bare bones. ... >> >> Don't implement malloc() yourself, there are others which have done >> a lot of research on that and which did it better. There are extremly >> fast malloc()-implementations like mimalloc from Microsoft Relsearch >> which is currently the fastest implementation. > > If I run the binary trees benchmark: > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html > > > then a version using normal malloc/free, compiled with gcc-O3, runs at > half the speed of my version using my own allocator. > > I don't know what malloc version gcc on Windows happens to use, but for > this purpose, mine is faster. > > (Mine is a small-object allocator implemented on top of larger memory > blocks obtained with any other allocator including malloc. It doesn't > need to store the block size, which helps.) > As seems to be the case so regularly, you don't know what you are doing when compiling and linking (you are often even unsure what your own home-made tools are doing), and yet you feel qualified to give opinions. There are many different ways to handle memory allocation, with different pros and cons, strengths and weaknesses. There are many different gcc builds for Windows, and many different C libraries that can be used with them. So all you actually know from your benchmarking is that some things are faster than others. Marvellous.
[toc] | [prev] | [next] | [standalone]
Page 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web