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 1 of 15 [1] 2 3 … 15 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-15 13:57 -0800 |
| Subject | A defer mechanism for C |
| Message-ID | <3a965b75-7eb6-4287-8e19-8969b6628d90n@googlegroups.com> |
https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/
[toc] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-16 02:11 +0300 |
| Message-ID | <20201216021146.ca064b8caaa4a51f9de2b800@gmail.com> |
| In reply to | #157279 |
Thiago Adams: > https://gustedt.wordpress.com/2020/12/14/a-defer- > mechanism-for-c/ Is it the first consturction that, if accepted, will break C's literal interpretation of control-flow statements by introcuding a kind of action at a distance (and over time)? All the other control-flow statements are executed immediately... -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-16 01:05 +0000 |
| Message-ID | <87czza4l1p.fsf@bsb.me.uk> |
| In reply to | #157281 |
Anton Shepelev <anton.txt@gmail.com> writes: > Thiago Adams: > >> https://gustedt.wordpress.com/2020/12/14/a-defer- >> mechanism-for-c/ > > Is it the first consturction that, if accepted, will break > C's literal interpretation of control-flow statements by > introcuding a kind of action at a distance (and over time)? > All the other control-flow statements are executed > immediately... It's not entirely unlike atexit() and at_quick_exit(), but I agree it's a significant departure. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-16 10:48 +0100 |
| Message-ID | <rrcl5s$t0p$1@dont-email.me> |
| In reply to | #157286 |
On 16/12/2020 02:05, Ben Bacarisse wrote: > Anton Shepelev <anton.txt@gmail.com> writes: > >> Thiago Adams: >> >>> https://gustedt.wordpress.com/2020/12/14/a-defer- >>> mechanism-for-c/ >> >> Is it the first consturction that, if accepted, will break >> C's literal interpretation of control-flow statements by >> introcuding a kind of action at a distance (and over time)? >> All the other control-flow statements are executed >> immediately... > > It's not entirely unlike atexit() and at_quick_exit(), but I agree it's > a significant departure. > It looks roughly like gcc's "cleanup" attribute, in that it lets you execute code when a variable goes out of scope. For me, the thing that looks most out of place with this is the syntax. It is suggesting a new syntax "defer <statement>" which takes a statement as a kind of parameter but does not execute it until later. That introduces all sorts of potential confusion. If you have "defer free(q);", is "q" captured when the "defer" statement is executed? What if "q" is changed later? What if a new "q" identifier is defined (a new local variable)? The whole thing looks like an attempt to get exceptions and destructors into C without having classes, and I really don't think it works. The solid majority of use-cases would for freeing allocated resources (and the solid majority of these would be memory). This can all be handled in a clearer and simpler way with gcc's cleanup attribute. Of course it would be possible to get a nicer standardised syntax for it, and it should be applicable to types as well as variables. But the result would be something that IMHO is simpler and clearer than this proposal, with far fewer changes to the language and existing implementations (bar a few details). I see this article is by Jens Gustedt. He is - as far as I know - one of the few C standards committee members that is visibly and publicly active and suggesting major new features in C. That's good, as a general point. But I think he is wrong in his attempts at making C more like C++. They are different languages, with different strengths and weaknesses. It's good to avoid unnecessary inconsistencies between them, but C will not benefit from being mangled into a kind of C+.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-16 04:16 -0800 |
| Message-ID | <b019393c-039b-4578-81a1-fed2d976674fn@googlegroups.com> |
| In reply to | #157290 |
On Wednesday, December 16, 2020 at 6:48:59 AM UTC-3, David Brown wrote: > On 16/12/2020 02:05, Ben Bacarisse wrote: > > Anton Shepelev <anto...@gmail.com> writes: > > > >> Thiago Adams: > >> > >>> https://gustedt.wordpress.com/2020/12/14/a-defer- > >>> mechanism-for-c/ > >> > >> Is it the first consturction that, if accepted, will break > >> C's literal interpretation of control-flow statements by > >> introcuding a kind of action at a distance (and over time)? > >> All the other control-flow statements are executed > >> immediately... > > > > It's not entirely unlike atexit() and at_quick_exit(), but I agree it's > > a significant departure. > > > It looks roughly like gcc's "cleanup" attribute, in that it lets you > execute code when a variable goes out of scope. > > For me, the thing that looks most out of place with this is the syntax. > It is suggesting a new syntax "defer <statement>" which takes a > statement as a kind of parameter but does not execute it until later. > That introduces all sorts of potential confusion. If you have "defer > free(q);", is "q" captured when the "defer" statement is executed? What > if "q" is changed later? What if a new "q" identifier is defined (a new > local variable)? Yes. C++ destructor is a kind of "simplified defer" because the meaning is fixed and the variable it needs is always the same and it is in the scope. The gcc cleanup also have this simplification. (I didn't see what is the capture mode for this defer proposal) > The whole thing looks like an attempt to get exceptions and destructors > into C without having classes, and I really don't think it works. I am not sure as well.. or if it works what is the runtime cost. > The solid majority of use-cases would for freeing allocated resources (and > the solid majority of these would be memory). This can all be handled > in a clearer and simpler way with gcc's cleanup attribute. Of course it > would be possible to get a nicer standardised syntax for it, and it > should be applicable to types as well as variables. But the result > would be something that IMHO is simpler and clearer than this proposal, > with far fewer changes to the language and existing implementations (bar > a few details). I think this proposal is too complex in terms of details and usage.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-16 17:04 +0100 |
| Message-ID | <rrdb61$n1e$1@dont-email.me> |
| In reply to | #157297 |
On 16/12/2020 13:16, Thiago Adams wrote: > On Wednesday, December 16, 2020 at 6:48:59 AM UTC-3, David Brown wrote: >> On 16/12/2020 02:05, Ben Bacarisse wrote: >>> Anton Shepelev <anto...@gmail.com> writes: >>> >>>> Thiago Adams: >>>> >>>>> https://gustedt.wordpress.com/2020/12/14/a-defer- >>>>> mechanism-for-c/ >>>> >>>> Is it the first consturction that, if accepted, will break >>>> C's literal interpretation of control-flow statements by >>>> introcuding a kind of action at a distance (and over time)? >>>> All the other control-flow statements are executed >>>> immediately... >>> >>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's >>> a significant departure. >>> >> It looks roughly like gcc's "cleanup" attribute, in that it lets you >> execute code when a variable goes out of scope. >> >> For me, the thing that looks most out of place with this is the syntax. >> It is suggesting a new syntax "defer <statement>" which takes a >> statement as a kind of parameter but does not execute it until later. >> That introduces all sorts of potential confusion. If you have "defer >> free(q);", is "q" captured when the "defer" statement is executed? What >> if "q" is changed later? What if a new "q" identifier is defined (a new >> local variable)? > > Yes. C++ destructor is a kind of "simplified defer" because the meaning > is fixed and the variable it needs is always the same and it is in the scope. "Simplified" depends on what you mean, and what you want to do with the operation. C++ destructors, especially combined with lambdas, will let you do anything you can do with this "defer" proposal. For some uses, C++ destructors will be a lot simpler, clearer and easier to get right - in other case, the "defer" syntax is likely to be easier and clearer. > The gcc cleanup also have this simplification. > > (I didn't see what is the capture mode for this defer proposal) > > >> The whole thing looks like an attempt to get exceptions and destructors >> into C without having classes, and I really don't think it works. > > I am not sure as well.. or if it works what is the runtime cost. > I expect that the run-time code generation will be pretty much what you would expect with a "goto" solution - just as it is for gcc "cleanup" or for C++ destructors (if there are no exceptions involved). >> The solid majority of use-cases would for freeing allocated resources (and >> the solid majority of these would be memory). This can all be handled >> in a clearer and simpler way with gcc's cleanup attribute. Of course it >> would be possible to get a nicer standardised syntax for it, and it >> should be applicable to types as well as variables. But the result >> would be something that IMHO is simpler and clearer than this proposal, >> with far fewer changes to the language and existing implementations (bar >> a few details). > > I think this proposal is too complex in terms of details and usage. > Agreed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-16 16:06 +0000 |
| Message-ID | <87h7ol3fd5.fsf@bsb.me.uk> |
| In reply to | #157290 |
David Brown <david.brown@hesbynett.no> writes: > On 16/12/2020 02:05, Ben Bacarisse wrote: >> Anton Shepelev <anton.txt@gmail.com> writes: >> >>> Thiago Adams: >>> >>>> https://gustedt.wordpress.com/2020/12/14/a-defer- >>>> mechanism-for-c/ >>> >>> Is it the first consturction that, if accepted, will break >>> C's literal interpretation of control-flow statements by >>> introcuding a kind of action at a distance (and over time)? >>> All the other control-flow statements are executed >>> immediately... >> >> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's >> a significant departure. >> > > It looks roughly like gcc's "cleanup" attribute, in that it lets you > execute code when a variable goes out of scope. But not quite. In the example given, the mutex mtx is not declared in the block so it's unlockingcan't be linked to the scope of mtx. And in general you can't unlock a mutex at the end of it's lifetime, only after a successful lock by the same thread. (Nit: better to say "at the end of it's lifetime". Identifiers often "go out of scope" before the end of the lifetime of the object they name.) > For me, the thing that looks most out of place with this is the > syntax. Must say I'm not a fan of the syntax. <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-17 15:26 +0100 |
| Message-ID | <rrfprg$bet$1@dont-email.me> |
| In reply to | #157309 |
On 16/12/2020 17:06, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 16/12/2020 02:05, Ben Bacarisse wrote:
>>> Anton Shepelev <anton.txt@gmail.com> writes:
>>>
>>>> Thiago Adams:
>>>>
>>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
>>>>> mechanism-for-c/
>>>>
>>>> Is it the first consturction that, if accepted, will break
>>>> C's literal interpretation of control-flow statements by
>>>> introcuding a kind of action at a distance (and over time)?
>>>> All the other control-flow statements are executed
>>>> immediately...
>>>
>>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's
>>> a significant departure.
>>>
>>
>> It looks roughly like gcc's "cleanup" attribute, in that it lets you
>> execute code when a variable goes out of scope.
>
> But not quite. In the example given, the mutex mtx is not declared in
> the block so it's unlockingcan't be linked to the scope of mtx. And in
> general you can't unlock a mutex at the end of it's lifetime, only after
> a successful lock by the same thread.
There are no doubt other differences. (I don't know the ordering of gcc
cleanup functions when multiple variables go out of scope at the same
time.) And yes, extra effort is needed for a gcc cleanup function to
handle the details around freeing the mutex.
>
> (Nit: better to say "at the end of it's lifetime". Identifiers often "go out
> of scope" before the end of the lifetime of the object they name.)
Yes, I know - but I'm not sure whether these defers and gcc cleanups are
run when the identifier goes out of scope or when their lifetime ends.
For block-scope local ("auto") variables in standard C, these are the
same point - when the block is exited. Since both cleanups and defer
are extensions or additions to C, that might change - and I don't know
which applies, or how well-defined the order is.
>
>> For me, the thing that looks most out of place with this is the
>> syntax.
>
> Must say I'm not a fan of the syntax.
>
> <cut>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-17 19:32 +0000 |
| Message-ID | <87czz81b4q.fsf@bsb.me.uk> |
| In reply to | #157342 |
David Brown <david.brown@hesbynett.no> writes:
> On 16/12/2020 17:06, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 16/12/2020 02:05, Ben Bacarisse wrote:
>>>> Anton Shepelev <anton.txt@gmail.com> writes:
>>>>
>>>>> Thiago Adams:
>>>>>
>>>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
>>>>>> mechanism-for-c/
>>>>>
>>>>> Is it the first consturction that, if accepted, will break
>>>>> C's literal interpretation of control-flow statements by
>>>>> introcuding a kind of action at a distance (and over time)?
>>>>> All the other control-flow statements are executed
>>>>> immediately...
>>>>
>>>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's
>>>> a significant departure.
>>>>
>>>
>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you
>>> execute code when a variable goes out of scope.
>>
>> But not quite. In the example given, the mutex mtx is not declared in
>> the block so it's unlockingcan't be linked to the scope of mtx. And in
>> general you can't unlock a mutex at the end of it's lifetime, only after
>> a successful lock by the same thread.
>
> There are no doubt other differences. (I don't know the ordering of gcc
> cleanup functions when multiple variables go out of scope at the same
> time.) And yes, extra effort is needed for a gcc cleanup function to
> handle the details around freeing the mutex.
Is it just details? Unlocking a mutex is not an action associated with
the object's lifetime so gcc's cleanup mechanism seems to be the wrong
thing.
>> (Nit: better to say "at the end of it's lifetime". Identifiers often "go out
>> of scope" before the end of the lifetime of the object they name.)
>
> Yes, I know - but I'm not sure whether these defers and gcc cleanups are
> run when the identifier goes out of scope or when their lifetime ends.
> For block-scope local ("auto") variables in standard C, these are the
> same point - when the block is exited.
That wasn't what I meant. In
void f(void) { int i = 42; g(); ... }
i will be not be in scope inside the body of g (though there may be
another i that is -- let's ignore that). Scope is a property of
identifiers and lifetime is a property of objects.
Of course they are linked because the lifetime of a declared object ends
when the flow of control passes beyond the end of the scope of the
object's name. That clumsy phrase is just me trying to avoid saying
what everyone says: "when the name goes out of scope" (and it may not
even capture all of the details).
In short, I prefer to talk about cleanup happening at the end of an
object's lifetime.
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-17 21:12 +0100 |
| Message-ID | <rrge36$74v$1@dont-email.me> |
| In reply to | #157351 |
On 17/12/2020 20:32, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 16/12/2020 17:06, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 16/12/2020 02:05, Ben Bacarisse wrote:
>>>>> Anton Shepelev <anton.txt@gmail.com> writes:
>>>>>
>>>>>> Thiago Adams:
>>>>>>
>>>>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
>>>>>>> mechanism-for-c/
>>>>>>
>>>>>> Is it the first consturction that, if accepted, will break
>>>>>> C's literal interpretation of control-flow statements by
>>>>>> introcuding a kind of action at a distance (and over time)?
>>>>>> All the other control-flow statements are executed
>>>>>> immediately...
>>>>>
>>>>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's
>>>>> a significant departure.
>>>>>
>>>>
>>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you
>>>> execute code when a variable goes out of scope.
>>>
>>> But not quite. In the example given, the mutex mtx is not declared in
>>> the block so it's unlockingcan't be linked to the scope of mtx. And in
>>> general you can't unlock a mutex at the end of it's lifetime, only after
>>> a successful lock by the same thread.
>>
>> There are no doubt other differences. (I don't know the ordering of gcc
>> cleanup functions when multiple variables go out of scope at the same
>> time.) And yes, extra effort is needed for a gcc cleanup function to
>> handle the details around freeing the mutex.
>
> Is it just details? Unlocking a mutex is not an action associated with
> the object's lifetime so gcc's cleanup mechanism seems to be the wrong
> thing.
>
In C++, a perfectly good way to handle mutexes is with a "lock" class -
constructing the class object locks the mutex, and destructing it
unlocks it. gcc's cleanup is the closest you get to a destructor in C
(with gcc extensions). Note that the cleanup is associated with the
lifetime of a lock object on the mutex, not the mutex itself.
(I'm not suggesting that using a cleanup function, or a defer, is
necessarily a good way to use a mutex in C.)
>>> (Nit: better to say "at the end of it's lifetime". Identifiers often "go out
>>> of scope" before the end of the lifetime of the object they name.)
>>
>> Yes, I know - but I'm not sure whether these defers and gcc cleanups are
>> run when the identifier goes out of scope or when their lifetime ends.
>> For block-scope local ("auto") variables in standard C, these are the
>> same point - when the block is exited.
>
> That wasn't what I meant. In
>
> void f(void) { int i = 42; g(); ... }
>
> i will be not be in scope inside the body of g (though there may be
> another i that is -- let's ignore that). Scope is a property of
> identifiers and lifetime is a property of objects.
>
Ah, okay.
> Of course they are linked because the lifetime of a declared object ends
> when the flow of control passes beyond the end of the scope of the
> object's name. That clumsy phrase is just me trying to avoid saying
> what everyone says: "when the name goes out of scope" (and it may not
> even capture all of the details).
>
> In short, I prefer to talk about cleanup happening at the end of an
> object's lifetime.
>
Fair enough. Yes, talking about lifetime would be a better choice than
scope here.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-17 13:10 -0800 |
| Message-ID | <6aa2bacc-6885-4052-aeb2-ed4fb0c8ac94n@googlegroups.com> |
| In reply to | #157355 |
On Thursday, 17 December 2020 at 20:12:37 UTC, David Brown wrote:
> On 17/12/2020 20:32, Ben Bacarisse wrote:
> > David Brown <david...@hesbynett.no> writes:
> >
> >> On 16/12/2020 17:06, Ben Bacarisse wrote:
> >>> David Brown <david...@hesbynett.no> writes:
> >>>
> >>>> On 16/12/2020 02:05, Ben Bacarisse wrote:
> >>>>> Anton Shepelev <anto...@gmail.com> writes:
> >>>>>
> >>>>>> Thiago Adams:
> >>>>>>
> >>>>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
> >>>>>>> mechanism-for-c/
> >>>>>>
> >>>>>> Is it the first consturction that, if accepted, will break
> >>>>>> C's literal interpretation of control-flow statements by
> >>>>>> introcuding a kind of action at a distance (and over time)?
> >>>>>> All the other control-flow statements are executed
> >>>>>> immediately...
> >>>>>
> >>>>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's
> >>>>> a significant departure.
> >>>>>
> >>>>
> >>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you
> >>>> execute code when a variable goes out of scope.
> >>>
> >>> But not quite. In the example given, the mutex mtx is not declared in
> >>> the block so it's unlockingcan't be linked to the scope of mtx. And in
> >>> general you can't unlock a mutex at the end of it's lifetime, only after
> >>> a successful lock by the same thread.
> >>
> >> There are no doubt other differences. (I don't know the ordering of gcc
> >> cleanup functions when multiple variables go out of scope at the same
> >> time.) And yes, extra effort is needed for a gcc cleanup function to
> >> handle the details around freeing the mutex.
> >
> > Is it just details? Unlocking a mutex is not an action associated with
> > the object's lifetime so gcc's cleanup mechanism seems to be the wrong
> > thing.
> >
> In C++, a perfectly good way to handle mutexes is with a "lock" class -
> constructing the class object locks the mutex, and destructing it
> unlocks it. gcc's cleanup is the closest you get to a destructor in C
> (with gcc extensions). Note that the cleanup is associated with the
> lifetime of a lock object on the mutex, not the mutex itself.
>
It's certainly a common paradigm.
You can argue about whether it is good. If we have this code
void setflag(bool value)
{
Mutex lock;
flag = value;
}
It's not obvious that "lock" is actually doing anything. It might be a stray
variable.And it's not obvious when the mutex is released. In fact code
is executed after "flag = value", but it's all hidden.
if we write
void setflag(bool value)
{
Lock lock = mutex();
flag = value;
releasemutex(&lock);
}
Now it's obvious that we're wrapping the command to "set flag" with two
portion of executable code, and that we're passing state created by the
first portion to the second portion.
Much easier to debug.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-18 11:35 +0100 |
| Message-ID | <rri0lu$5gt$1@dont-email.me> |
| In reply to | #157359 |
On 17/12/2020 22:10, Malcolm McLean wrote:
> On Thursday, 17 December 2020 at 20:12:37 UTC, David Brown wrote:
>> On 17/12/2020 20:32, Ben Bacarisse wrote:
>>> David Brown <david...@hesbynett.no> writes:
>>>
>>>> On 16/12/2020 17:06, Ben Bacarisse wrote:
>>>>> David Brown <david...@hesbynett.no> writes:
>>>>>
>>>>>> On 16/12/2020 02:05, Ben Bacarisse wrote:
>>>>>>> Anton Shepelev <anto...@gmail.com> writes:
>>>>>>>
>>>>>>>> Thiago Adams:
>>>>>>>>
>>>>>>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
>>>>>>>>> mechanism-for-c/
>>>>>>>>
>>>>>>>> Is it the first consturction that, if accepted, will break
>>>>>>>> C's literal interpretation of control-flow statements by
>>>>>>>> introcuding a kind of action at a distance (and over time)?
>>>>>>>> All the other control-flow statements are executed
>>>>>>>> immediately...
>>>>>>>
>>>>>>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's
>>>>>>> a significant departure.
>>>>>>>
>>>>>>
>>>>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you
>>>>>> execute code when a variable goes out of scope.
>>>>>
>>>>> But not quite. In the example given, the mutex mtx is not declared in
>>>>> the block so it's unlockingcan't be linked to the scope of mtx. And in
>>>>> general you can't unlock a mutex at the end of it's lifetime, only after
>>>>> a successful lock by the same thread.
>>>>
>>>> There are no doubt other differences. (I don't know the ordering of gcc
>>>> cleanup functions when multiple variables go out of scope at the same
>>>> time.) And yes, extra effort is needed for a gcc cleanup function to
>>>> handle the details around freeing the mutex.
>>>
>>> Is it just details? Unlocking a mutex is not an action associated with
>>> the object's lifetime so gcc's cleanup mechanism seems to be the wrong
>>> thing.
>>>
>> In C++, a perfectly good way to handle mutexes is with a "lock" class -
>> constructing the class object locks the mutex, and destructing it
>> unlocks it. gcc's cleanup is the closest you get to a destructor in C
>> (with gcc extensions). Note that the cleanup is associated with the
>> lifetime of a lock object on the mutex, not the mutex itself.
>>
> It's certainly a common paradigm.
>
> You can argue about whether it is good. If we have this code
>
> void setflag(bool value)
> {
> Mutex lock;
>
> flag = value;
> }
>
> It's not obvious that "lock" is actually doing anything. It might be a stray
> variable.And it's not obvious when the mutex is released. In fact code
> is executed after "flag = value", but it's all hidden.
If you are using C++, you accept that code is regularly run despite
being "hidden" - that is the nature of constructors, destructors,
operator overloads, etc. This should not be a surprise.
But if you want to write clear and understandable code, it is vital to
use appropriate names and terms - regardless of the programming
language, and regardless of the way the code is structured. And the
code you wrote above shows a complete misunderstanding of locks and
mutexes. The mutex needs to be a single mutex that is tied to the data
to protect, and the lock needs to be taken on that mutex.
Appropriate C++ code here could be:
bool flag;
std::mutex flag_mutex;
void setflag(bool value) {
const std::scoped_lock lock(flag_mutex);
flag = value;
}
This is far clearer. Look at the name - "scoped_lock". It's clear that
this lock is held for the scope of the variable. (The same applies to
the older, and sometimes useful, "lock_guard" type.)
>
> if we write
>
> void setflag(bool value)
> {
> Lock lock = mutex();
> flag = value;
> releasemutex(&lock);
> }
> Now it's obvious that we're wrapping the command to "set flag" with two
> portion of executable code, and that we're passing state created by the
> first portion to the second portion.
Sure (baring the same mistake about how mutexes actually work). That's
the C way - do things manually, in the open. It's clear what is going
on, and everything is written out manually. Equally, it's easy to
forget things when code gets bigger.
The C way and the C++ way are different. They each have their
advantages and disadvantages. The point is that adding a "defer" to C
to make something a bit like C++ is a bad idea, IMHO.
>
> Much easier to debug.
>
No, there you are wrong.
The C++ method is easier to debug because it is less likely that you
will have an error in the first place. The challenge to debugging locks
and threaded code is not the obvious stuff where you've forgotten to put
an unlock in simple code like this - even if you don't notice when
writing the code, you'll see it the first time you test. The challenge
is for unusual cases - things that almost never happen during testing.
And you handle these primarily by getting the code right in the first
place, not by finding the bugs - usually the fewer lines of code you
need, the fewer opportunities you have for getting it wrong. A classic
case for mutexes would be:
std::mutex mut_a;
std::mutex mut_b;
void foo1(void) {
const std::scoped_lock lock(mut_a, mut_b);
do_something();
}
vs.
void foo2(void) {
mtx_lock(mut_a);
mtx_lock(mut_b);
do_something();
mtx_unlock(mut_a);
mtx_unlock(mut_b);
}
The C "foo2" looks simple and clear, and in all your testing it will
work. But it has a bug - and Murphy's law says it will only hit when
the code is in use at the end user, not when testing in the lab. The
C++ solution (or gcc cleanup, or the proposed defer) won't have that
problem.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-18 06:05 -0800 |
| Message-ID | <0b136e48-e0e7-45f4-a6de-8a5406cefff2n@googlegroups.com> |
| In reply to | #157382 |
On Friday, 18 December 2020 at 10:35:58 UTC, David Brown wrote:
> On 17/12/2020 22:10, Malcolm McLean wrote:
> > On Thursday, 17 December 2020 at 20:12:37 UTC, David Brown wrote:
> >> On 17/12/2020 20:32, Ben Bacarisse wrote:
> >>> David Brown <david...@hesbynett.no> writes:
> >>>
> >>>> On 16/12/2020 17:06, Ben Bacarisse wrote:
> >>>>> David Brown <david...@hesbynett.no> writes:
> >>>>>
> >>>>>> On 16/12/2020 02:05, Ben Bacarisse wrote:
> >>>>>>> Anton Shepelev <anto...@gmail.com> writes:
> >>>>>>>
> >>>>>>>> Thiago Adams:
> >>>>>>>>
> >>>>>>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
> >>>>>>>>> mechanism-for-c/
> >>>>>>>>
> >>>>>>>> Is it the first consturction that, if accepted, will break
> >>>>>>>> C's literal interpretation of control-flow statements by
> >>>>>>>> introcuding a kind of action at a distance (and over time)?
> >>>>>>>> All the other control-flow statements are executed
> >>>>>>>> immediately...
> >>>>>>>
> >>>>>>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's
> >>>>>>> a significant departure.
> >>>>>>>
> >>>>>>
> >>>>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you
> >>>>>> execute code when a variable goes out of scope.
> >>>>>
> >>>>> But not quite. In the example given, the mutex mtx is not declared in
> >>>>> the block so it's unlockingcan't be linked to the scope of mtx. And in
> >>>>> general you can't unlock a mutex at the end of it's lifetime, only after
> >>>>> a successful lock by the same thread.
> >>>>
> >>>> There are no doubt other differences. (I don't know the ordering of gcc
> >>>> cleanup functions when multiple variables go out of scope at the same
> >>>> time.) And yes, extra effort is needed for a gcc cleanup function to
> >>>> handle the details around freeing the mutex.
> >>>
> >>> Is it just details? Unlocking a mutex is not an action associated with
> >>> the object's lifetime so gcc's cleanup mechanism seems to be the wrong
> >>> thing.
> >>>
> >> In C++, a perfectly good way to handle mutexes is with a "lock" class -
> >> constructing the class object locks the mutex, and destructing it
> >> unlocks it. gcc's cleanup is the closest you get to a destructor in C
> >> (with gcc extensions). Note that the cleanup is associated with the
> >> lifetime of a lock object on the mutex, not the mutex itself.
> >>
> > It's certainly a common paradigm.
> >
> > You can argue about whether it is good. If we have this code
> >
> > void setflag(bool value)
> > {
> > Mutex lock;
> >
> > flag = value;
> > }
> >
> > It's not obvious that "lock" is actually doing anything. It might be a stray
> > variable.And it's not obvious when the mutex is released. In fact code
> > is executed after "flag = value", but it's all hidden.
> If you are using C++, you accept that code is regularly run despite
> being "hidden" - that is the nature of constructors, destructors,
> operator overloads, etc. This should not be a surprise.
>
> But if you want to write clear and understandable code, it is vital to
> use appropriate names and terms - regardless of the programming
> language, and regardless of the way the code is structured. And the
> code you wrote above shows a complete misunderstanding of locks and
> mutexes. The mutex needs to be a single mutex that is tied to the data
> to protect, and the lock needs to be taken on that mutex.
>
That's the C++ standard library mutex.
If you are using a standard library mutex then you can be pretty certain
that there will be no bugs in the implementation itself.
However if you are just using a "Mutex" you can't be so sure.
We use a higher-level "suite lock" which is similar to a mutex, but the
interface is just to declare a "suite lock" variable. I haven't used C++ standard
library mutexes. This is another issue. You mustn't assume that other
people are necessarily familiar with the platform you happen to use.
Particularly if you are talking about C++ in a C programmng group.
>
> The C++ method is easier to debug because it is less likely that you
> will have an error in the first place. The challenge to debugging locks
> and threaded code is not the obvious stuff where you've forgotten to put
> an unlock in simple code like this - even if you don't notice when
> writing the code, you'll see it the first time you test. The challenge
> is for unusual cases - things that almost never happen during testing.
> And you handle these primarily by getting the code right in the first
> place, not by finding the bugs - usually the fewer lines of code you
> need, the fewer opportunities you have for getting it wrong. A classic
> case for mutexes would be:
>
That is a good point. What matters is dangerous bugs, not bugs which will
come out on the first informal test after successfully compiling.
But you can only rely on your bug not appearing in the C++ if you can
rely on the person who wrote the scoped_lock() destructor. Which you can,
if it's in the standard library or some other well-established and debugged
library. But not when it's a peer-produced mutex in an active development
environment.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-18 15:28 +0100 |
| Message-ID | <rriead$8k2$1@dont-email.me> |
| In reply to | #157387 |
On 18/12/2020 15:05, Malcolm McLean wrote:
> On Friday, 18 December 2020 at 10:35:58 UTC, David Brown wrote:
>> On 17/12/2020 22:10, Malcolm McLean wrote:
>>> On Thursday, 17 December 2020 at 20:12:37 UTC, David Brown wrote:
>>>> On 17/12/2020 20:32, Ben Bacarisse wrote:
>>>>> David Brown <david...@hesbynett.no> writes:
>>>>>
>>>>>> On 16/12/2020 17:06, Ben Bacarisse wrote:
>>>>>>> David Brown <david...@hesbynett.no> writes:
>>>>>>>
>>>>>>>> On 16/12/2020 02:05, Ben Bacarisse wrote:
>>>>>>>>> Anton Shepelev <anto...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> Thiago Adams:
>>>>>>>>>>
>>>>>>>>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
>>>>>>>>>>> mechanism-for-c/
>>>>>>>>>>
>>>>>>>>>> Is it the first consturction that, if accepted, will break
>>>>>>>>>> C's literal interpretation of control-flow statements by
>>>>>>>>>> introcuding a kind of action at a distance (and over time)?
>>>>>>>>>> All the other control-flow statements are executed
>>>>>>>>>> immediately...
>>>>>>>>>
>>>>>>>>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's
>>>>>>>>> a significant departure.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you
>>>>>>>> execute code when a variable goes out of scope.
>>>>>>>
>>>>>>> But not quite. In the example given, the mutex mtx is not declared in
>>>>>>> the block so it's unlockingcan't be linked to the scope of mtx. And in
>>>>>>> general you can't unlock a mutex at the end of it's lifetime, only after
>>>>>>> a successful lock by the same thread.
>>>>>>
>>>>>> There are no doubt other differences. (I don't know the ordering of gcc
>>>>>> cleanup functions when multiple variables go out of scope at the same
>>>>>> time.) And yes, extra effort is needed for a gcc cleanup function to
>>>>>> handle the details around freeing the mutex.
>>>>>
>>>>> Is it just details? Unlocking a mutex is not an action associated with
>>>>> the object's lifetime so gcc's cleanup mechanism seems to be the wrong
>>>>> thing.
>>>>>
>>>> In C++, a perfectly good way to handle mutexes is with a "lock" class -
>>>> constructing the class object locks the mutex, and destructing it
>>>> unlocks it. gcc's cleanup is the closest you get to a destructor in C
>>>> (with gcc extensions). Note that the cleanup is associated with the
>>>> lifetime of a lock object on the mutex, not the mutex itself.
>>>>
>>> It's certainly a common paradigm.
>>>
>>> You can argue about whether it is good. If we have this code
>>>
>>> void setflag(bool value)
>>> {
>>> Mutex lock;
>>>
>>> flag = value;
>>> }
>>>
>>> It's not obvious that "lock" is actually doing anything. It might be a stray
>>> variable.And it's not obvious when the mutex is released. In fact code
>>> is executed after "flag = value", but it's all hidden.
>> If you are using C++, you accept that code is regularly run despite
>> being "hidden" - that is the nature of constructors, destructors,
>> operator overloads, etc. This should not be a surprise.
>>
>> But if you want to write clear and understandable code, it is vital to
>> use appropriate names and terms - regardless of the programming
>> language, and regardless of the way the code is structured. And the
>> code you wrote above shows a complete misunderstanding of locks and
>> mutexes. The mutex needs to be a single mutex that is tied to the data
>> to protect, and the lock needs to be taken on that mutex.
>>
> That's the C++ standard library mutex.
> If you are using a standard library mutex then you can be pretty certain
> that there will be no bugs in the implementation itself.
>
> However if you are just using a "Mutex" you can't be so sure.
Of course that's true. After all, you could use a type called "Mutex"
that actually represents a matrix combined with a typo.
Back in the real world, if you want to use a mutex to control access to
a resource, then you need /one/ mutex object for each access controller
you have, and anything using the resource needs to lock that particular
mutex. You can't have your own local mutex as an automatic (stack)
variable in the function that uses the resource (the "flag" variable in
this case).
So either the code is completely wrong because the author does not
understand how to use mutexes, or the name of the type is completely
wrong because the author does not know the difference between a mutex
and locking a mutex.
>
> We use a higher-level "suite lock" which is similar to a mutex, but the
> interface is just to declare a "suite lock" variable. I haven't used C++ standard
> library mutexes. This is another issue. You mustn't assume that other
> people are necessarily familiar with the platform you happen to use.
> Particularly if you are talking about C++ in a C programmng group.
I assume merely that someone talking about mutexes knows what a mutex
is. No more than that. (Mutexes are standard in C too, by the way,
with similar functionality within the limits of the C language.)
Let's take an analogy.
You have a precious object that lives in a museum's locked room with one
key. You want to be sure that no more than one person enters the room
at a time. So you employ a watchman that keeps hold of the key.
Visitors ask the watchman for the key, go into the room, come out, and
give the key back to the watchman.
The watchman is the "mutex". Getting the key is "acquiring the mutex",
or "locking the mutex". Giving the key back is "releasing the mutex" or
"unlocking the mutex".
If you are using a local variable to represent holding the mutex, then
it represents the act of holding the key - it doesn't even necessarily
have any data in it.
But having a "Mutex" as the local variable - whether it be the C++
standard type, the C11 standard type, or any other mutex type - is the
analogue of bringing your own watchman along to the museum. It is
obvious that it cannot be of any help whatsoever.
> >
>> The C++ method is easier to debug because it is less likely that you
>> will have an error in the first place. The challenge to debugging locks
>> and threaded code is not the obvious stuff where you've forgotten to put
>> an unlock in simple code like this - even if you don't notice when
>> writing the code, you'll see it the first time you test. The challenge
>> is for unusual cases - things that almost never happen during testing.
>> And you handle these primarily by getting the code right in the first
>> place, not by finding the bugs - usually the fewer lines of code you
>> need, the fewer opportunities you have for getting it wrong. A classic
>> case for mutexes would be:
>>
> That is a good point. What matters is dangerous bugs, not bugs which will
> come out on the first informal test after successfully compiling.
>
Agreed.
> But you can only rely on your bug not appearing in the C++ if you can
> rely on the person who wrote the scoped_lock() destructor. Which you can,
> if it's in the standard library or some other well-established and debugged
> library. But not when it's a peer-produced mutex in an active development
> environment.
>
Sure. The same principle applies to any code - and it applies equally
to C++ RAII style code and explicit C style code.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-18 08:49 -0800 |
| Message-ID | <a7dffc11-3e67-4d38-a744-b209fd62475cn@googlegroups.com> |
| In reply to | #157391 |
On Friday, 18 December 2020 at 14:28:43 UTC, David Brown wrote:
> On 18/12/2020 15:05, Malcolm McLean wrote:
> > On Friday, 18 December 2020 at 10:35:58 UTC, David Brown wrote:
> >> On 17/12/2020 22:10, Malcolm McLean wrote:
> >>> On Thursday, 17 December 2020 at 20:12:37 UTC, David Brown wrote:
> >>>> On 17/12/2020 20:32, Ben Bacarisse wrote:
> >>>>> David Brown <david...@hesbynett.no> writes:
> >>>>>
> >>>>>> On 16/12/2020 17:06, Ben Bacarisse wrote:
> >>>>>>> David Brown <david...@hesbynett.no> writes:
> >>>>>>>
> >>>>>>>> On 16/12/2020 02:05, Ben Bacarisse wrote:
> >>>>>>>>> Anton Shepelev <anto...@gmail.com> writes:
> >>>>>>>>>
> >>>>>>>>>> Thiago Adams:
> >>>>>>>>>>
> >>>>>>>>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
> >>>>>>>>>>> mechanism-for-c/
> >>>>>>>>>>
> >>>>>>>>>> Is it the first consturction that, if accepted, will break
> >>>>>>>>>> C's literal interpretation of control-flow statements by
> >>>>>>>>>> introcuding a kind of action at a distance (and over time)?
> >>>>>>>>>> All the other control-flow statements are executed
> >>>>>>>>>> immediately...
> >>>>>>>>>
> >>>>>>>>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's
> >>>>>>>>> a significant departure.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you
> >>>>>>>> execute code when a variable goes out of scope.
> >>>>>>>
> >>>>>>> But not quite. In the example given, the mutex mtx is not declared in
> >>>>>>> the block so it's unlockingcan't be linked to the scope of mtx. And in
> >>>>>>> general you can't unlock a mutex at the end of it's lifetime, only after
> >>>>>>> a successful lock by the same thread.
> >>>>>>
> >>>>>> There are no doubt other differences. (I don't know the ordering of gcc
> >>>>>> cleanup functions when multiple variables go out of scope at the same
> >>>>>> time.) And yes, extra effort is needed for a gcc cleanup function to
> >>>>>> handle the details around freeing the mutex.
> >>>>>
> >>>>> Is it just details? Unlocking a mutex is not an action associated with
> >>>>> the object's lifetime so gcc's cleanup mechanism seems to be the wrong
> >>>>> thing.
> >>>>>
> >>>> In C++, a perfectly good way to handle mutexes is with a "lock" class -
> >>>> constructing the class object locks the mutex, and destructing it
> >>>> unlocks it. gcc's cleanup is the closest you get to a destructor in C
> >>>> (with gcc extensions). Note that the cleanup is associated with the
> >>>> lifetime of a lock object on the mutex, not the mutex itself.
> >>>>
> >>> It's certainly a common paradigm.
> >>>
> >>> You can argue about whether it is good. If we have this code
> >>>
> >>> void setflag(bool value)
> >>> {
> >>> Mutex lock;
> >>>
> >>> flag = value;
> >>> }
> >>>
> >>> It's not obvious that "lock" is actually doing anything. It might be a stray
> >>> variable.And it's not obvious when the mutex is released. In fact code
> >>> is executed after "flag = value", but it's all hidden.
> >> If you are using C++, you accept that code is regularly run despite
> >> being "hidden" - that is the nature of constructors, destructors,
> >> operator overloads, etc. This should not be a surprise.
> >>
> >> But if you want to write clear and understandable code, it is vital to
> >> use appropriate names and terms - regardless of the programming
> >> language, and regardless of the way the code is structured. And the
> >> code you wrote above shows a complete misunderstanding of locks and
> >> mutexes. The mutex needs to be a single mutex that is tied to the data
> >> to protect, and the lock needs to be taken on that mutex.
> >>
> > That's the C++ standard library mutex.
> > If you are using a standard library mutex then you can be pretty certain
> > that there will be no bugs in the implementation itself.
> >
> > However if you are just using a "Mutex" you can't be so sure.
> Of course that's true. After all, you could use a type called "Mutex"
> that actually represents a matrix combined with a typo.
>
> Back in the real world, if you want to use a mutex to control access to
> a resource, then you need /one/ mutex object for each access controller
> you have, and anything using the resource needs to lock that particular
> mutex. You can't have your own local mutex as an automatic (stack)
> variable in the function that uses the resource (the "flag" variable in
> this case).
>
> So either the code is completely wrong because the author does not
> understand how to use mutexes, or the name of the type is completely
> wrong because the author does not know the difference between a mutex
> and locking a mutex.
>
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();
}
}
Maybe Mutex isn't the right name for this class. It's not as powerful as the
C++ standard lbrary mutxes as you can only have one of them, but then
maybe you only need one.
> >
> > We use a higher-level "suite lock" which is similar to a mutex, but the
> > interface is just to declare a "suite lock" variable. I haven't used C++ standard
> > library mutexes. This is another issue. You mustn't assume that other
> > people are necessarily familiar with the platform you happen to use.
> > Particularly if you are talking about C++ in a C programmng group.
> I assume merely that someone talking about mutexes knows what a mutex
> is. No more than that. (Mutexes are standard in C too, by the way,
> with similar functionality within the limits of the C language.)
>
> Let's take an analogy.
>
> You have a precious object that lives in a museum's locked room with one
> key. You want to be sure that no more than one person enters the room
> at a time. So you employ a watchman that keeps hold of the key.
> Visitors ask the watchman for the key, go into the room, come out, and
> give the key back to the watchman.
>
> The watchman is the "mutex". Getting the key is "acquiring the mutex",
> or "locking the mutex". Giving the key back is "releasing the mutex" or
> "unlocking the mutex".
>
> If you are using a local variable to represent holding the mutex, then
> it represents the act of holding the key - it doesn't even necessarily
> have any data in it.
>
> But having a "Mutex" as the local variable - whether it be the C++
> standard type, the C11 standard type, or any other mutex type - is the
> analogue of bringing your own watchman along to the museum. It is
> obvious that it cannot be of any help whatsoever.
>
It could hog the processor on creation and release on deletion. Not
all threads run on a multi-core system.
There are lots of possibilities.
>
> > But you can only rely on your bug not appearing in the C++ if you can
> > rely on the person who wrote the scoped_lock() destructor. Which you can,
> > if it's in the standard library or some other well-established and debugged
> > library. But not when it's a peer-produced mutex in an active development
> > environment.
> >
> Sure. The same principle applies to any code - and it applies equally
> to C++ RAII style code and explicit C style code.
>
OK, so I supect that something is wrong with release_mutex.
In C, I simply do this
printf("Releasing mutex\n");
release_mutex(&mutex):
printf("Released mutex\n"):
That will probably tell me a lot.
In C++ and RAII, it can be lot more difficult.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-18 18:24 +0100 |
| Message-ID | <rriojn$nf0$1@dont-email.me> |
| In reply to | #157399 |
On 18/12/2020 17:49, Malcolm McLean wrote:
> On Friday, 18 December 2020 at 14:28:43 UTC, David Brown wrote:
>> On 18/12/2020 15:05, Malcolm McLean wrote:
>>> On Friday, 18 December 2020 at 10:35:58 UTC, David Brown wrote:
>>>> On 17/12/2020 22:10, Malcolm McLean wrote:
>>>>> On Thursday, 17 December 2020 at 20:12:37 UTC, David Brown wrote:
>>>>>> On 17/12/2020 20:32, Ben Bacarisse wrote:
>>>>>>> David Brown <david...@hesbynett.no> writes:
>>>>>>>
>>>>>>>> On 16/12/2020 17:06, Ben Bacarisse wrote:
>>>>>>>>> David Brown <david...@hesbynett.no> writes:
>>>>>>>>>
>>>>>>>>>> On 16/12/2020 02:05, Ben Bacarisse wrote:
>>>>>>>>>>> Anton Shepelev <anto...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> Thiago Adams:
>>>>>>>>>>>>
>>>>>>>>>>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
>>>>>>>>>>>>> mechanism-for-c/
>>>>>>>>>>>>
>>>>>>>>>>>> Is it the first consturction that, if accepted, will break
>>>>>>>>>>>> C's literal interpretation of control-flow statements by
>>>>>>>>>>>> introcuding a kind of action at a distance (and over time)?
>>>>>>>>>>>> All the other control-flow statements are executed
>>>>>>>>>>>> immediately...
>>>>>>>>>>>
>>>>>>>>>>> It's not entirely unlike atexit() and at_quick_exit(), but I agree it's
>>>>>>>>>>> a significant departure.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It looks roughly like gcc's "cleanup" attribute, in that it lets you
>>>>>>>>>> execute code when a variable goes out of scope.
>>>>>>>>>
>>>>>>>>> But not quite. In the example given, the mutex mtx is not declared in
>>>>>>>>> the block so it's unlockingcan't be linked to the scope of mtx. And in
>>>>>>>>> general you can't unlock a mutex at the end of it's lifetime, only after
>>>>>>>>> a successful lock by the same thread.
>>>>>>>>
>>>>>>>> There are no doubt other differences. (I don't know the ordering of gcc
>>>>>>>> cleanup functions when multiple variables go out of scope at the same
>>>>>>>> time.) And yes, extra effort is needed for a gcc cleanup function to
>>>>>>>> handle the details around freeing the mutex.
>>>>>>>
>>>>>>> Is it just details? Unlocking a mutex is not an action associated with
>>>>>>> the object's lifetime so gcc's cleanup mechanism seems to be the wrong
>>>>>>> thing.
>>>>>>>
>>>>>> In C++, a perfectly good way to handle mutexes is with a "lock" class -
>>>>>> constructing the class object locks the mutex, and destructing it
>>>>>> unlocks it. gcc's cleanup is the closest you get to a destructor in C
>>>>>> (with gcc extensions). Note that the cleanup is associated with the
>>>>>> lifetime of a lock object on the mutex, not the mutex itself.
>>>>>>
>>>>> It's certainly a common paradigm.
>>>>>
>>>>> You can argue about whether it is good. If we have this code
>>>>>
>>>>> void setflag(bool value)
>>>>> {
>>>>> Mutex lock;
>>>>>
>>>>> flag = value;
>>>>> }
>>>>>
>>>>> It's not obvious that "lock" is actually doing anything. It might be a stray
>>>>> variable.And it's not obvious when the mutex is released. In fact code
>>>>> is executed after "flag = value", but it's all hidden.
>>>> If you are using C++, you accept that code is regularly run despite
>>>> being "hidden" - that is the nature of constructors, destructors,
>>>> operator overloads, etc. This should not be a surprise.
>>>>
>>>> But if you want to write clear and understandable code, it is vital to
>>>> use appropriate names and terms - regardless of the programming
>>>> language, and regardless of the way the code is structured. And the
>>>> code you wrote above shows a complete misunderstanding of locks and
>>>> mutexes. The mutex needs to be a single mutex that is tied to the data
>>>> to protect, and the lock needs to be taken on that mutex.
>>>>
>>> That's the C++ standard library mutex.
>>> If you are using a standard library mutex then you can be pretty certain
>>> that there will be no bugs in the implementation itself.
>>>
>>> However if you are just using a "Mutex" you can't be so sure.
>> Of course that's true. After all, you could use a type called "Mutex"
>> that actually represents a matrix combined with a typo.
>>
>> Back in the real world, if you want to use a mutex to control access to
>> a resource, then you need /one/ mutex object for each access controller
>> you have, and anything using the resource needs to lock that particular
>> mutex. You can't have your own local mutex as an automatic (stack)
>> variable in the function that uses the resource (the "flag" variable in
>> this case).
>>
>> So either the code is completely wrong because the author does not
>> understand how to use mutexes, or the name of the type is completely
>> wrong because the author does not know the difference between a mutex
>> and locking a mutex.
>>
> 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();
> }
> }
>
> Maybe Mutex isn't the right name for this class. It's not as powerful as the
> C++ standard lbrary mutxes as you can only have one of them, but then
> maybe you only need one.
That is not a mutex. It is not even close to being a working lock of
any kind, except in the very specific case of an OS on a single core
with only one thread priority level and a round-robin scheduler. You've
made a class and called it a "Mutex" when it is, at best, a mutex locker
object - /not/ a lock itself. I really hope you are not involved in
implementing any of this kind of thing, or even using threads, mutexes
or locks in code.
>>>
>>> We use a higher-level "suite lock" which is similar to a mutex, but the
>>> interface is just to declare a "suite lock" variable. I haven't used C++ standard
>>> library mutexes. This is another issue. You mustn't assume that other
>>> people are necessarily familiar with the platform you happen to use.
>>> Particularly if you are talking about C++ in a C programmng group.
>> I assume merely that someone talking about mutexes knows what a mutex
>> is. No more than that. (Mutexes are standard in C too, by the way,
>> with similar functionality within the limits of the C language.)
>>
>> Let's take an analogy.
>>
>> You have a precious object that lives in a museum's locked room with one
>> key. You want to be sure that no more than one person enters the room
>> at a time. So you employ a watchman that keeps hold of the key.
>> Visitors ask the watchman for the key, go into the room, come out, and
>> give the key back to the watchman.
>>
>> The watchman is the "mutex". Getting the key is "acquiring the mutex",
>> or "locking the mutex". Giving the key back is "releasing the mutex" or
>> "unlocking the mutex".
>>
>> If you are using a local variable to represent holding the mutex, then
>> it represents the act of holding the key - it doesn't even necessarily
>> have any data in it.
>>
>> But having a "Mutex" as the local variable - whether it be the C++
>> standard type, the C11 standard type, or any other mutex type - is the
>> analogue of bringing your own watchman along to the museum. It is
>> obvious that it cannot be of any help whatsoever.
>>
> It could hog the processor on creation and release on deletion. Not
> all threads run on a multi-core system.
My threads almost all run on single-core systems. "Hogging" the
processor for a time is not a mutex - it is a critical section. (And
yes, I am fully aware that on some systems critical sections are all you
need, and you don't need mutexes at all. But that would be different
discussion.)
>
> There are lots of possibilities.
There are indeed many possibilities of how one might implement a mutex,
and how one might have an API for using them. None match what you have
been writing, however.
>>
>>> But you can only rely on your bug not appearing in the C++ if you can
>>> rely on the person who wrote the scoped_lock() destructor. Which you can,
>>> if it's in the standard library or some other well-established and debugged
>>> library. But not when it's a peer-produced mutex in an active development
>>> environment.
>>>
>> Sure. The same principle applies to any code - and it applies equally
>> to C++ RAII style code and explicit C style code.
>>
> OK, so I supect that something is wrong with release_mutex.
> In C, I simply do this
>
> printf("Releasing mutex\n");
> release_mutex(&mutex):
> printf("Released mutex\n"):
>
> That will probably tell me a lot.
>
> In C++ and RAII, it can be lot more difficult.
>
Your difficulty lies in your apparent misunderstandings of mutexes. You
can't hope to use them correctly in C or C++ when you don't know what
they are.
Perhaps once you have learned that, you will be in a position to judge
whether you personally find it easier to write the code with or without
RAII.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-18 10:31 -0800 |
| Message-ID | <28c625f7-61a9-452a-9b17-d0a2fe126f85n@googlegroups.com> |
| In reply to | #157402 |
On Friday, 18 December 2020 at 17:24:21 UTC, David Brown wrote:
> On 18/12/2020 17:49, 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();
> > }
> > }
> >
> > Maybe Mutex isn't the right name for this class. It's not as powerful as the
> > C++ standard lbrary mutxes as you can only have one of them, but then
> > maybe you only need one.
> That is not a mutex. It is not even close to being a working lock of
> any kind, except in the very specific case of an OS on a single core
> with only one thread priority level and a round-robin scheduler. You've
> made a class and called it a "Mutex" when it is, at best, a mutex locker
> object - /not/ a lock itself. I really hope you are not involved in
> implementing any of this kind of thing, or even using threads, mutexes
> or locks in code.
>
It's not written for any specific architecture, just a sort of generalised
threading system. That's how these sorts of systems are put together.
The details vary from platform to platform.
> Your difficulty lies in your apparent misunderstandings of mutexes. You
> can't hope to use them correctly in C or C++ when you don't know what
> they are.
>
> Perhaps once you have learned that, you will be in a position to judge
> whether you personally find it easier to write the code with or without
> RAII.
>
Implementing mutexs or programming with threads isn't something I
do. But I have done it before. It's not relevant to what I'm currently
doing and hasn't been for some time.
Essentially when implementing these types of programs you are dealing
with a human-designed system, which you are using in a manner
intended by its designers. That's a different programming problem to
the ones I'm interested in.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-19 16:53 +0100 |
| Message-ID | <rrl7m8$rv3$1@dont-email.me> |
| In reply to | #157406 |
On 18/12/2020 19:31, Malcolm McLean wrote:
> On Friday, 18 December 2020 at 17:24:21 UTC, David Brown wrote:
>> On 18/12/2020 17:49, 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();
>>> }
>>> }
>>>
>>> Maybe Mutex isn't the right name for this class. It's not as powerful as the
>>> C++ standard lbrary mutxes as you can only have one of them, but then
>>> maybe you only need one.
>> That is not a mutex. It is not even close to being a working lock of
>> any kind, except in the very specific case of an OS on a single core
>> with only one thread priority level and a round-robin scheduler. You've
>> made a class and called it a "Mutex" when it is, at best, a mutex locker
>> object - /not/ a lock itself. I really hope you are not involved in
>> implementing any of this kind of thing, or even using threads, mutexes
>> or locks in code.
>>
> It's not written for any specific architecture, just a sort of generalised
> threading system. That's how these sorts of systems are put together.
> The details vary from platform to platform.
>
"Generalised" would imply that it works on a wide range of systems, but
is perhaps not optimal on particular systems. Your code just doesn't
work except in an unrealistic specific case. It is not a matter of
"details" - it's a matter of not understanding the problem in any way,
at any level.
When you are in a hole, stop digging. And you are in a big hole here.
Please simply accept that since this is not the type of coding you do,
you don't know enough to continue the discussion. Feel free to /ask/
about things if you want - but kindly stop posting nonsense. Some of us
are neurotic about leaving completely wrong postings unchallenged on the
internet, and this is just wasting everyone's time.
>> Your difficulty lies in your apparent misunderstandings of mutexes. You
>> can't hope to use them correctly in C or C++ when you don't know what
>> they are.
>>
>> Perhaps once you have learned that, you will be in a position to judge
>> whether you personally find it easier to write the code with or without
>> RAII.
>>
> Implementing mutexs or programming with threads isn't something I
> do. But I have done it before. It's not relevant to what I'm currently
> doing and hasn't been for some time.
> Essentially when implementing these types of programs you are dealing
> with a human-designed system, which you are using in a manner
> intended by its designers. That's a different programming problem to
> the ones I'm interested in.
>
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 19:33 +0100 |
| Message-ID | <rrismj$lt5$1@dont-email.me> |
| In reply to | #157399 |
class Mutex
> {
> static bool aquired = false;
>
> Mutex()
> {
> while (acquired)
> yield();
> disable_interrupts();
> acquired = true;
> enable_interrupts();
> }
> ~Mutex()
> {
> disable_interrupts();
> acquired = false;
> enable_interrupts();
> }
> }
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.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-18 11:06 -0800 |
| Message-ID | <a3e65634-d587-43c0-8ab3-f4cf0a423a1fn@googlegroups.com> |
| In reply to | #157407 |
On Friday, 18 December 2020 at 18:34:11 UTC, Bonita Montero wrote:
> class Mutex
> > {
> > static bool aquired = false;
> >
> > Mutex()
> > {
> > while (acquired)
> > yield();
> > disable_interrupts();
> > acquired = true;
> > enable_interrupts();
> > }
> > ~Mutex()
> > {
> > disable_interrupts();
> > acquired = false;
> > enable_interrupts();
> > }
> > }
> 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. Then the system brings it back to life in its
own good time. You would probably have to disable interrupts on the
read as well as the write, but it's not real code for a real system, just
example code to give the broad outline of how the class would work.
[toc] | [prev] | [next] | [standalone]
Page 1 of 15 [1] 2 3 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web