Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #92512 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2016-08-19 14:22 -0700 |
| Last post | 2016-08-22 05:11 -0700 |
| Articles | 20 on this page of 355 — 30 participants |
Back to article view | Back to comp.lang.c
Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:22 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 09:36 +1200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 22:48 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:56 -0700
Re: Default values in #define Chad <cdalten@gmail.com> - 2016-08-22 07:56 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 17:09 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:47 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:55 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 09:27 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 09:41 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 20:19 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 12:54 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:14 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:23 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 05:42 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:52 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 06:01 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:06 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:56 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:59 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-23 10:42 -0700
Re: Default values in #define matt@godbolt.org - 2016-08-23 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:57 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:31 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:06 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:15 -0700
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 13:26 +0100
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-05 22:07 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-06 06:22 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 00:50 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-07 06:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 01:44 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-08 06:58 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:16 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:47 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:49 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:52 -0800
Re: Default values in #define asetofsymbols@gmail.com - 2016-12-09 00:52 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:19 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-07 04:43 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 14:18 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 07:22 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 08:00 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 22:14 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 13:44 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:07 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-09 17:00 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 17:46 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:37 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-10 09:42 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 10:05 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:51 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 04:40 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 03:15 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-12 16:12 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-13 01:45 -0600
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 16:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 10:25 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 10:50 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 04:02 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 13:14 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:57 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 14:32 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:58 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:21 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 14:41 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:47 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 16:24 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 07:30 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:12 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 12:21 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 15:02 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 13:19 -0800
Petty and unprofessional (Was: Default values in #define) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-13 16:46 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 09:04 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 20:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:19 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-13 11:33 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:44 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-14 10:04 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:37 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:28 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:23 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:10 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:54 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:57 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 02:53 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 05:59 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:03 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:22 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 17:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 18:37 -0800
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:25 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 07:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:35 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 09:17 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 11:03 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 11:41 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 12:31 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 13:13 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-12 20:22 +0000
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 14:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 07:10 -0800
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:21 -0800
Re: Default values in #define jameskuyper@verizon.net - 2016-12-11 10:33 -0800
Re: Default values in #define Melzzzzz <mel@zzzzz.com> - 2016-12-11 16:22 +0100
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:16 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 13:54 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 14:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:11 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:49 -0700
Re: Default values in #define Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-21 05:50 -0600
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-21 13:10 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 12:56 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 21:11 +0100
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-22 15:47 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 11:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 20:07 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 14:30 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-24 06:25 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 10:34 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-24 08:50 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 15:37 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 11:58 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 01:27 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 22:28 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 23:38 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:44 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 07:29 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 07:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:26 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 11:11 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 12:03 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:31 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 09:28 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 22:51 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 16:35 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 01:44 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-30 10:06 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:41 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:24 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:32 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-30 22:30 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 09:17 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:46 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 10:29 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:12 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 12:30 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 11:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:56 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 08:17 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:18 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:34 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 00:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:19 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 11:38 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 10:03 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 10:31 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 12:50 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 21:30 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:37 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 08:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-06 07:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:54 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-02 08:40 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 10:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 15:16 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-25 08:28 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 00:54 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 01:00 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 11:17 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 04:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 13:45 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 06:09 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 17:11 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 09:31 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 12:48 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:50 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:01 +0200
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 10:57 -0700
Re: Default values in #define Ike Naar <ike@iceland.freeshell.org> - 2016-08-31 06:09 +0000
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 12:24 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:39 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:49 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:51 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:46 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-26 17:37 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 15:05 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 10:25 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 16:25 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 18:12 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 13:47 +1200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 19:32 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 22:54 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 21:11 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 18:25 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:11 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 06:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 10:16 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:17 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:26 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:10 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:35 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:28 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 15:38 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 13:27 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 16:42 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:16 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 17:24 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:21 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 08:12 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 15:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 10:53 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:34 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 14:44 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 12:48 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:19 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 11:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:33 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:51 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:46 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 16:26 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-03 17:31 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:03 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:36 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:30 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:39 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 03:57 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 15:34 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 07:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:46 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:03 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:52 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 07:41 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 14:58 -0400
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:27 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:05 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:15 -0700
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-09-02 22:22 +0200
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-28 08:41 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:34 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:41 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 08:07 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:08 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 15:41 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:30 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:14 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 23:37 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:19 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:26 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 04:40 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:56 +0200
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 15:43 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 19:34 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 00:51 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 20:36 +1200
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-08-31 00:39 -0500
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 21:40 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:22 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 11:36 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:26 -0800
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-27 06:34 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 12:48 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:12 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:10 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:18 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 10:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:49 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:13 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:48 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:14 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 08:59 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:43 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-29 22:58 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-30 07:14 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 00:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 00:26 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:10 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 10:47 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 03:32 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:38 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:44 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 14:00 +0200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 18:55 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:24 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 14:11 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 16:28 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 16:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-31 06:27 +0100
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 23:09 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 16:06 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:35 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:30 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:40 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:17 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:58 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 09:09 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:16 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:49 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:31 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:24 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:29 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 10:02 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:33 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 14:12 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 14:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:27 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 23:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 14:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:32 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:33 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 06:13 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:35 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 19:08 +0100
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-08-24 09:05 +0200
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-24 00:49 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-24 05:40 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-19 22:56 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 10:14 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 18:09 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 13:15 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 19:10 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 14:50 +1200
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 10:35 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-20 03:13 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 12:24 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-21 00:14 +1200
Re: Default values in #define gazelle@shell.xmission.com (Kenny McCormack) - 2016-08-20 14:13 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:17 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 14:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:14 -0700
Re: Default values in #define Philipp Klaus Krause <pkk@spth.de> - 2016-08-21 12:51 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:11 -0700
Page 15 of 18 — ← Prev page 1 … 13 14 [15] 16 17 18 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-29 23:13 +0200 |
| Message-ID | <nq28il$9fn$1@dont-email.me> |
| In reply to | #92883 |
On 29/08/16 19:18, supercat@casperkitty.com wrote:
> On Monday, August 29, 2016 at 9:10:14 AM UTC-5, David Brown wrote:
>> You cannot expect that the compiler will generate instructions for
>> ordering or flushing any cpu write-back buffers, or handling caches, or
>> synchronising amongst other processors on a multi-core system. You
>> cannot expect that the compiler will do any ordering with respect to
>> non-volatile accesses.
>
> Do you mean "cannot expect that a compiler will refrain from reordering
> non-volatile accesses across volatile ones?
Er, yes. Sorry about that.
>
>> And this is a /good/ thing. Any code that involves "volatile" is
>> low-level code, and efficiency is often a major concern (for
>> application-level code you would typically use OS-provided
>> synchronisation primitives, or call drivers or HAL functions for
>> register access). You don't want extra instructions here - especially
>> not synchronisation ones that can be very costly.
>
> Who's asking for synchronization instructions? Since an embedded
> programmer is likely to know more about the target hardware's memory
> configuration than the compiler writer, the programmer should be
> responsible for doing whatever the hardware requires to ensure that
> the effects of any store instructions *which have already executed*
> are made visible to whatever needs to see them (e.g. by writing a
> suitable command-word to the cache controller). If the programmer
> knows what needs to happen at the hardware level, a quality compiler
> should stay out of the way.
And that is exactly what the compiler is doing with "volatile" - staying
out of the programmer's way, and not doing anything other than handling
volatile accesses.
(I don't actually agree that programmers know more than compiler writers
in all cases - some cases, yes, but not others. Compiler-provided
atomic memory synchronisation primitives are a good idea.)
>
> I am well aware that for whatever reason it has become fashionable for
> compilers to move memory operations, even to things whose semantics are
> not constrained via "restrict", across volatile-qualified accesses. I
> also do not doubt that there are some application fields where that is
> useful.
>
It is not a matter of "being fashionable". It's a matter of compiler
optimisation. Unnecessary loads and stores are removed or re-ordered
for efficiency. For many systems, loads and stores are bottlenecks, and
moving them around can make a huge difference to the run-time efficiency
of the program. You seem to imagine that there has been a specific step
between "old" behaviour of all memory operations being ordered to "new"
behaviour where memory operations are re-ordered to be "cool and
trendy", disregarding the wishes of programmers. In fact, compilers
have simply got better, and newer processors need more sophisticated
optimisations to get the best run-time efficiency. This reordering has
always been allowed.
> I would suggest, however, that in many other cases the optimizations that
> enables are minor compared with the optimizations that are impeded by
> requiring that everything which is ever accessed in "volatile" fashion
> must always be treated as "volatile", rather than allowing things to be
> treated with normal memory semantics except when code performs "volatile"
> accesses.
You can suggest all you want - but back it up with references or numbers
if you want me to believe it. In particular, show me how a compiler
that considered volatile accesses to be memory barriers (or at least,
compiler barriers - thanks to Chris for insisting on precision here)
would generate more efficient code than can be done with a real life
compiler and careful use of volatile and implementation-dependent
features such as asm("":::"memory").
>
> Can you think of any reason the authors of the Standard would have neglected
> to mandate any sort of compiler-level barrier to memory reordering which
> would be syntactically equivalent to calling a function whose internals are
> unknown to the compiler, if they did not intend that "volatile" would act as
> such sufficient barrier to explicit barrier directives unnecessary? The
> need for such barriers is just about as common as the need for "volatile",
> and any compiler should be able to implement them. It seems antithetical
> to the idea of a "standard" that it should require adding *compiler-specific*
> extensions to code which had previously been compiler-agnostic.
>
The standards authors were smart, but they could not think of
everything. However, they were smart enough to know this, and allowed
for implementation-defined behaviour to fill in gaps that were needed in
real programming situations.
As far as I can see, your reasoning here (and in many places), seems to be:
1. The standards say A.
2. You think they should say B.
3. You can't write a piece of code that you want, in the way that you
want, in a portable manner, unless the standards said B.
4. You therefore think that the standards really say, or imply, B. Or
at least, some old standard said or implied B.
It turns out that in most cases, you /can/ write the code in 3 - you
just can't do it in a fully portable way, because it requires
implementation dependent behaviour.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 14:48 -0700 |
| Message-ID | <b3e6b882-370c-4170-896d-c4871da70440@googlegroups.com> |
| In reply to | #92904 |
On Monday, August 29, 2016 at 4:14:05 PM UTC-5, David Brown wrote: > On 29/08/16 19:18, supercat wrote: > > If the programmer > > knows what needs to happen at the hardware level, a quality compiler > > should stay out of the way. > > And that is exactly what the compiler is doing with "volatile" - staying > out of the programmer's way, and not doing anything other than handling > volatile accesses. I'd say handling them properly sequenced with regard to the surrounding program state should also be an essential part of that, in the absence of options or directives expressly waiving such behavioral guarantees. > (I don't actually agree that programmers know more than compiler writers > in all cases - some cases, yes, but not others. Compiler-provided > atomic memory synchronisation primitives are a good idea.) Sometimes compiler writers know more, and sometimes programmers do. I'm 100% certain that I know more about the memory behavioral model of one of my projects some years back than the compiler writer could possibly have known, since the hardware hadn't even been designed when the compiler was written. On that compiler, calls to external functions served as memory barriers, but the system would have been horrendously inefficient if everything that needed to be guarded by compiler barriers at discrete points in time had to be declared "volatile", versus being able to have something that could act as a compiler barrier at those moments where one was needed. > > I am well aware that for whatever reason it has become fashionable for > > compilers to move memory operations, even to things whose semantics are > > not constrained via "restrict", across volatile-qualified accesses. I > > also do not doubt that there are some application fields where that is > > useful. > > > > It is not a matter of "being fashionable". It's a matter of compiler > optimisation. Unnecessary loads and stores are removed or re-ordered > for efficiency. For many systems, loads and stores are bottlenecks, and > moving them around can make a huge difference to the run-time efficiency > of the program. You seem to imagine that there has been a specific step > between "old" behaviour of all memory operations being ordered to "new" > behaviour where memory operations are re-ordered to be "cool and > trendy", disregarding the wishes of programmers. In fact, compilers > have simply got better, and newer processors need more sophisticated > optimisations to get the best run-time efficiency. This reordering has > always been allowed. Volatile loads and stores are often associated with low-level I/O, for which precise semantics are often more important than code efficiency (if code doesn't work, speed is irrelevant). I have never disputed that the Standard allows the reordering, nor that there are some cases where it has great benefits and few drawbacks. There are also many cases where forcing programmers to defend against unwanted reorderings will greatly impair efficiency. I would also question whether the notion of a "standard" is well-served by requiring that code which wants to efficiently use a particular piece of hardware must use compiler-specific directives to ensure correct operation, rather than suggesting that quality compilers targeting hardware and projects where such things are likely to matter should default to an ordering model that favors semantics in the absence of directives specifying otherwise. > 1. The standards say A. > 2. You think they should say B. > 3. You can't write a piece of code that you want, in the way that you > want, in a portable manner, unless the standards said B. > 4. You therefore think that the standards really say, or imply, B. Or > at least, some old standard said or implied B. There are some platforms and projects where doing A would be a good thing. There are others for which it a guarantee that a compiler won't do A would be vastly more useful. A compiler may say that a compiler can do A without being non-conforming, but that's not the same thing as saying that a compiler can do A without making itself unsuitable for purposes it could otherwise fulfill.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-26 09:14 -0700 |
| Message-ID | <00a1b8c8-bec1-45bb-9351-0399038274de@googlegroups.com> |
| In reply to | #92718 |
On Friday, August 26, 2016 at 7:45:35 AM UTC-5, Ben Bacarisse wrote: > Yes. These rely on implementation-defined guarantees. Unfortunately, from what I've seen, compiler documentation seldom bothers to guarantee particular behaviors in cases where the compiler writers can't imagine any sane compiler for the target platform doing anything else, and even more rarely provides any easy way for a programmer to easily identify whether a compiler will behave in a fashion that is, or at least used to be, commonplace. As such, they are "guaranteed" in the same sense that if someone buys a can of soda it is "guaranteed" to be have an opening mechanism on the top so it can be drunk without a can opener. If a customer buys a case of soda cans that lack built-in openers, should the company respond by saying that it never promised to include opening devices?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-26 08:59 -0700 |
| Message-ID | <925ce09c-a5ad-4327-a79c-dc95a586770e@googlegroups.com> |
| In reply to | #92715 |
On Friday, August 26, 2016 at 6:08:35 AM UTC-5, Malcolm McLean wrote: > On Friday, August 26, 2016 at 11:17:47 AM UTC+1, Ben Bacarisse wrote: > > Maybe you have a broader concept of what's a detail than I do, but > > unless there is some magic involved, a single atomic flag won't work > > even with two threads using the buffer as above. I think supercat is > > thinking that there will only ever be one thread putting data in the > > buffer. Than again, you may not be suggesting that this scheme > > generalises -- I was not sure exactly what your point was. > > > The problem is contention for a resource, two things trying to access it > at the same time. So the solution is a flag or token. Only if you hold the > token can you use the resource, and you must give it back as soon as you > are done. On a single-core system, if the instructions that write the buffer can be guaranteed to execute before the later instructions in the same thread that set the ready flag, and if the instructions that read the buffer can be guaranteed not to execute until after a test of the ready flag has confirmed that the buffer is ready, there is no difficulty. The difficulty is that in C, the only way to guarantee that is to make all accesses to the buffer "volatile", which then means that it cannot be written efficiently with things like memcpy. The most efficient approach using purely features described in the C Standard would likely be to use memcpy to copy the source data into a uint64_t[] (or maybe uint32_t), copy that one value at a time into a uint64_t volatile[], and then write a volatile flag to indicate that the buffer is ready (if memcpy can copy 32 or more bits at a time, and the user-code loop can do likewise, the cost of copying the data twice that way may be less than the cost of reading it fro the source a byte at a time using `char*`. > It's not easy, but the basic flag or token concept is sound and is used in > practiced. It should be sound on many hardware platforms, and there's no good reason it should require the use of compiler-specific extensions on such platforms, but it does. I'm curious what optimizations would be enabled in real-world use cases that would not be enabled by suitable use of "restrict" [if one assumes that operations on pointers in "restrict"- qualified variables are unsequenced relative to operations on anything *whose address cannot have been derived from such pointers*]. Language rules that mandate the use of one or two extra copy steps that a compiler can't optimize out would have a rather high cost, so I would think the extra optimizations that are enabled by allowing compilers to resequence non-qualified operations across volatile-qualified ones would have to be pretty impressive to justify that cost. > People hooked up processors to IO ports that sent data at unpredictable > intervals long before 2011. You can write a token system in most dialects > of C. But supercat might be right, theoretically an aggressive or perverse > optimiser could wreck the system if it moves the buffer access outside > the token guards. My complaint is that it is fashionable for compiler writers to base their optimizations upon what the Standard allows, without regard for whether that would make it impossible to achieve good performance without relying upon compiler-specific extensions, and there's no general way to know what will work on any given compiler without having to read a lot of documentation for it (which makes it impossible to write efficient code which can be safely ported to any compiler the author doesn't know about). A much more helpful approach would be to say that unless code specifies otherwise, volatile operations act as compiler memory barriers (though not necessarily hardware barriers) with regard to anything that might be hit by "*someVolatileCharPointer += 1;". If achieving a desired level of performance would require using a directive to waive that requirement, failure to use the directive may yield sub-optimal performance, but that is a far less severe problem than having code arbitrarily fail.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-29 15:43 +0200 |
| Message-ID | <nq1e6o$qvk$1@dont-email.me> |
| In reply to | #92715 |
On 26/08/16 13:08, Malcolm McLean wrote: > People hooked up processors to IO ports that sent data at unpredictable > intervals long before 2011. You can write a token system in most dialects > of C. But supercat might be right, theoretically an aggressive or perverse > optimiser could wreck the system if it moves the buffer access outside > the token guards. > Please don't listen to Supercat here. He is either ignorant, or being intentionally confusing. There is nothing theoretical or aggressive about a compiler re-ordering non-volatile accesses with respect to volatile ones - it is part of common compiler optimisations. And as Ben says, this is a well-understood issue with well-understood solutions. The only "problem" occurs when people who /don't/ understand the issues present incorrect "solutions" or make false claims about what compilers do or did "in the good old days".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-29 22:58 -0700 |
| Message-ID | <3f6534af-ec82-4d9e-8f9c-e4805dec99db@googlegroups.com> |
| In reply to | #92861 |
On Monday, August 29, 2016 at 2:44:00 PM UTC+1, David Brown wrote: > On 26/08/16 13:08, Malcolm McLean wrote: > > > People hooked up processors to IO ports that sent data at unpredictable > > intervals long before 2011. You can write a token system in most dialects > > of C. But supercat might be right, theoretically an aggressive or perverse > > optimiser could wreck the system if it moves the buffer access outside > > the token guards. > > > > Please don't listen to Supercat here. He is either ignorant, or being > intentionally confusing. There is nothing theoretical or aggressive > about a compiler re-ordering non-volatile accesses with respect to > volatile ones - it is part of common compiler optimisations. And as Ben > says, this is a well-understood issue with well-understood solutions. > The only "problem" occurs when people who /don't/ understand the issues > present incorrect "solutions" or make false claims about what compilers > do or did "in the good old days". > I see. So if we implement a semaphore / token /flag system, the buffer must also be volatile, even though in fact it can't change when the accessor has the token, to prevent the optimiser moving the buffer accesses from outside the token guards.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-30 07:14 +0100 |
| Message-ID | <87shtmokah.fsf@gmail.com> |
| In reply to | #92918 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > I see. So if we implement a semaphore / token /flag system, the > buffer must also be volatile, even though in fact it can't change when > the accessor has the token, to prevent the optimiser moving the buffer > accesses from outside the token guards. Use a memory barrier in the token acquisition/release code. Buffer accesses will not be re-ordered through the memory barrier.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-30 00:14 -0700 |
| Message-ID | <nq3boo$35i$1@dont-email.me> |
| In reply to | #92918 |
On 8/29/2016 10:58 PM, Malcolm McLean wrote: > On Monday, August 29, 2016 at 2:44:00 PM UTC+1, David Brown wrote: >> On 26/08/16 13:08, Malcolm McLean wrote: >> >>> People hooked up processors to IO ports that sent data at unpredictable >>> intervals long before 2011. You can write a token system in most dialects >>> of C. But supercat might be right, theoretically an aggressive or perverse >>> optimiser could wreck the system if it moves the buffer access outside >>> the token guards. >>> >> >> Please don't listen to Supercat here. He is either ignorant, or being >> intentionally confusing. There is nothing theoretical or aggressive >> about a compiler re-ordering non-volatile accesses with respect to >> volatile ones - it is part of common compiler optimisations. And as Ben >> says, this is a well-understood issue with well-understood solutions. >> The only "problem" occurs when people who /don't/ understand the issues >> present incorrect "solutions" or make false claims about what compilers >> do or did "in the good old days". >> > I see. > So if we implement a semaphore / token /flag system, the buffer must also > be volatile, even though in fact it can't change when the accessor has > the token, to prevent the optimiser moving the buffer accesses from > outside the token guards. You can use volatile and cross your fingers. However, I prefer to use the std atomics/membars when available, or resort to some custom asm wrt implementing a synchronization algorithm. Then, you know where everything is. ;^)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-30 00:26 -0700 |
| Message-ID | <f38b5411-cba9-429b-8748-6d1951a98b50@googlegroups.com> |
| In reply to | #92921 |
On Tuesday, August 30, 2016 at 8:14:43 AM UTC+1, Chris M. Thomasson wrote:
> On 8/29/2016 10:58 PM, Malcolm McLean wrote:
> > On Monday, August 29, 2016 at 2:44:00 PM UTC+1, David Brown wrote:
> >> On 26/08/16 13:08, Malcolm McLean wrote:
> >>
> >>> People hooked up processors to IO ports that sent data at unpredictable
> >>> intervals long before 2011. You can write a token system in most dialects
> >>> of C. But supercat might be right, theoretically an aggressive or perverse
> >>> optimiser could wreck the system if it moves the buffer access outside
> >>> the token guards.
> >>>
> >>
> >> Please don't listen to Supercat here. He is either ignorant, or being
> >> intentionally confusing. There is nothing theoretical or aggressive
> >> about a compiler re-ordering non-volatile accesses with respect to
> >> volatile ones - it is part of common compiler optimisations. And as Ben
> >> says, this is a well-understood issue with well-understood solutions.
> >> The only "problem" occurs when people who /don't/ understand the issues
> >> present incorrect "solutions" or make false claims about what compilers
> >> do or did "in the good old days".
> >>
> > I see.
> > So if we implement a semaphore / token /flag system, the buffer must also
> > be volatile, even though in fact it can't change when the accessor has
> > the token, to prevent the optimiser moving the buffer accesses from
> > outside the token guards.
>
> You can use volatile and cross your fingers. However, I prefer to use
> the std atomics/membars when available, or resort to some custom asm wrt
> implementing a synchronization algorithm. Then, you know where
> everything is. ;^)
>
When I actually did this sort of thing.
volatile char flag = 0;
if(flag == 0)
{
flag = 1;
do_your_stuff();
flag = 0;
}
was fine. You could run as many threads as you wanted.
If everything has become more complex then that is sad, except of
course in the case where you can have contention for flag - that's
something that can be inherently hard to solve if the underlying
hardware doesn't allow two threads to access the same memory
essentially at the same time.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-08-30 02:10 -0700 |
| Message-ID | <8b95c448-59b5-43e8-ac58-265b1b09c49d@googlegroups.com> |
| In reply to | #92922 |
On Tuesday, August 30, 2016 at 10:26:47 AM UTC+3, Malcolm McLean wrote:
> On Tuesday, August 30, 2016 at 8:14:43 AM UTC+1, Chris M. Thomasson wrote:
> > On 8/29/2016 10:58 PM, Malcolm McLean wrote:
> > > On Monday, August 29, 2016 at 2:44:00 PM UTC+1, David Brown wrote:
> > >> On 26/08/16 13:08, Malcolm McLean wrote:
> > >>
> > >>> People hooked up processors to IO ports that sent data at unpredictable
> > >>> intervals long before 2011. You can write a token system in most dialects
> > >>> of C. But supercat might be right, theoretically an aggressive or perverse
> > >>> optimiser could wreck the system if it moves the buffer access outside
> > >>> the token guards.
> > >>>
> > >>
> > >> Please don't listen to Supercat here. He is either ignorant, or being
> > >> intentionally confusing. There is nothing theoretical or aggressive
> > >> about a compiler re-ordering non-volatile accesses with respect to
> > >> volatile ones - it is part of common compiler optimisations. And as Ben
> > >> says, this is a well-understood issue with well-understood solutions.
> > >> The only "problem" occurs when people who /don't/ understand the issues
> > >> present incorrect "solutions" or make false claims about what compilers
> > >> do or did "in the good old days".
> > >>
> > > I see.
> > > So if we implement a semaphore / token /flag system, the buffer must also
> > > be volatile, even though in fact it can't change when the accessor has
> > > the token, to prevent the optimiser moving the buffer accesses from
> > > outside the token guards.
> >
> > You can use volatile and cross your fingers. However, I prefer to use
> > the std atomics/membars when available, or resort to some custom asm wrt
> > implementing a synchronization algorithm. Then, you know where
> > everything is. ;^)
> >
> When I actually did this sort of thing.
>
> volatile char flag = 0;
>
> if(flag == 0)
> {
> flag = 1;
> do_your_stuff();
> flag = 0;
> }
>
> was fine. You could run as many threads as you wanted.
Regardless of compiler issues, I don't understand in which situation the code above will work*. Looks like it contains very obvious race condition between flag check and flag set. Atomic compare-and-set was invented exactly for this case.
---------
* - may be, it will work on single-processor system with real-time thread scheduler, with single writer always running in context of higher priority than one or multiple readers.
> If everything has become more complex then that is sad, except of
> course in the case where you can have contention for flag - that's
> something that can be inherently hard to solve if the underlying
> hardware doesn't allow two threads to access the same memory
> essentially at the same time.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-30 10:47 +0100 |
| Message-ID | <87fupmy4e3.fsf@bsb.me.uk> |
| In reply to | #92922 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> When I actually did this sort of thing.
>
> volatile char flag = 0;
>
> if(flag == 0)
> {
> flag = 1;
> do_your_stuff();
> flag = 0;
> }
>
> was fine. You could run as many threads as you wanted.
Not, I hope, in a pacemaker -- there is nothing to prevent two threads
seeing flag == 0.
You've spoken before about games programming and the idea that getting
incorrect results quickly is sometimes desirable. That may have been
the context where you actually did this sort of thing -- where a
violation of mutual exclusion might won't be a critical failure -- but
I'd always want to announce that about such code.
> If everything has become more complex then that is sad,
Things have become more complex, but it was never this simple. Even
with the very simplest memory systems of the 1960s, the above won't
work. Where early machines lacked atomic test-and-set instructions (or
similar) you'd have to use a more complex algorithm, such as Dekker or
Peterson. It's ironic that Peterson's simple algorithm was discovered
rather late, once almost every machine had hardware support for
shared-memory concurrency control.
> except of
> course in the case where you can have contention for flag - that's
> something that can be inherently hard to solve if the underlying
> hardware doesn't allow two threads to access the same memory
> essentially at the same time.
Testing and, later, setting a flag is logically incorrect even if (a)
accesses are atomic, (b) concurrent access is permitted.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-30 03:32 -0700 |
| Message-ID | <8b76677f-88e2-4d46-8a5b-ed8f58bf0ea3@googlegroups.com> |
| In reply to | #92930 |
On Tuesday, August 30, 2016 at 10:47:58 AM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> <snip>
> > When I actually did this sort of thing.
> >
> > volatile char flag = 0;
> >
> > if(flag == 0)
> > {
> > flag = 1;
> > do_your_stuff();
> > flag = 0;
> > }
> >
> > was fine. You could run as many threads as you wanted.
>
> Not, I hope, in a pacemaker -- there is nothing to prevent two threads
> seeing flag == 0.
>
> You've spoken before about games programming and the idea that getting
> incorrect results quickly is sometimes desirable. That may have been
> the context where you actually did this sort of thing -- where a
> violation of mutual exclusion might won't be a critical failure -- but
> I'd always want to announce that about such code.
>
The interrupt occurs between the if() and the flag = 1?
The thing is the interrupt routine disables interrupts. So the thread sees 0.
The interrupt routine interrupts at that point, and also sees zero. the
interrupt routine then does its stuff and plays about with buffer. Control
returns to the main thread. The flag is now set to one. The main thread
then plays about with the buffer. There's another interrupt, but now the
flag is one, so the interrupt routine doesn't fiddle about with the buffer
but does its stuff in a secondary or reserve buffer. main thread sets the
flag to zero. theres a third interrupt, and now the interrupt routine does its
stuff.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-30 13:38 +0200 |
| Message-ID | <nq3r84$g0l$1@dont-email.me> |
| In reply to | #92932 |
On 30/08/16 12:32, Malcolm McLean wrote:
> On Tuesday, August 30, 2016 at 10:47:58 AM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> <snip>
>>> When I actually did this sort of thing.
>>>
>>> volatile char flag = 0;
>>>
>>> if(flag == 0)
>>> {
>>> flag = 1;
>>> do_your_stuff();
>>> flag = 0;
>>> }
>>>
>>> was fine. You could run as many threads as you wanted.
>>
>> Not, I hope, in a pacemaker -- there is nothing to prevent two threads
>> seeing flag == 0.
>>
>> You've spoken before about games programming and the idea that getting
>> incorrect results quickly is sometimes desirable. That may have been
>> the context where you actually did this sort of thing -- where a
>> violation of mutual exclusion might won't be a critical failure -- but
>> I'd always want to announce that about such code.
>>
> The interrupt occurs between the if() and the flag = 1?
You said specifically "you could run as many threads as you wanted".
That's a very different situation from a background task synchronising
with an interrupt task.
>
> The thing is the interrupt routine disables interrupts. So the thread sees 0.
> The interrupt routine interrupts at that point, and also sees zero. the
> interrupt routine then does its stuff and plays about with buffer. Control
> returns to the main thread. The flag is now set to one. The main thread
> then plays about with the buffer. There's another interrupt, but now the
> flag is one, so the interrupt routine doesn't fiddle about with the buffer
> but does its stuff in a secondary or reserve buffer. main thread sets the
> flag to zero. theres a third interrupt, and now the interrupt routine does its
> stuff.
>
Such reasoning can often be valid for the case of interrupts, because
the interrupt can break into the main thread, but not vice versa, and
because the interrupt function runs to completion before the main thread
regains control. This lets you use much simpler locking and
synchronisation mechanisms than general pre-emptive multi-threading.
But if you are limiting yourself to just interrupts, then please say so
- don't say "threads".
>
>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-30 04:44 -0700 |
| Message-ID | <579b0bdd-f174-4b6f-bc48-24921d83eea4@googlegroups.com> |
| In reply to | #92937 |
On Tuesday, August 30, 2016 at 12:38:52 PM UTC+1, David Brown wrote:
> On 30/08/16 12:32, Malcolm McLean wrote:
> > On Tuesday, August 30, 2016 at 10:47:58 AM UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >> <snip>
> >>> When I actually did this sort of thing.
> >>>
> >>> volatile char flag = 0;
> >>>
> >>> if(flag == 0)
> >>> {
> >>> flag = 1;
> >>> do_your_stuff();
> >>> flag = 0;
> >>> }
> >>>
> >>> was fine. You could run as many threads as you wanted.
> >>
> >> Not, I hope, in a pacemaker -- there is nothing to prevent two threads
> >> seeing flag == 0.
> >>
> >> You've spoken before about games programming and the idea that getting
> >> incorrect results quickly is sometimes desirable. That may have been
> >> the context where you actually did this sort of thing -- where a
> >> violation of mutual exclusion might won't be a critical failure -- but
> >> I'd always want to announce that about such code.
> >>
> > The interrupt occurs between the if() and the flag = 1?
>
> You said specifically "you could run as many threads as you wanted".
> That's a very different situation from a background task synchronising
> with an interrupt task.
>
Yes, the way it used to work way you had threads which yielded at various points.
So if a thread yielded, another thread would take over. But a thread couldn't be
interrupted to start another thread, unless in yield().
Then the interrupt service routines could break in any time.
>
> Such reasoning can often be valid for the case of interrupts, because
> the interrupt can break into the main thread, but not vice versa, and
> because the interrupt function runs to completion before the main thread
> regains control. This lets you use much simpler locking and
> synchronisation mechanisms than general pre-emptive multi-threading.
>
> But if you are limiting yourself to just interrupts, then please say so
> - don't say "threads".
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-30 14:00 +0200 |
| Message-ID | <nq3shf$jud$1@dont-email.me> |
| In reply to | #92940 |
On 30/08/16 13:44, Malcolm McLean wrote:
> On Tuesday, August 30, 2016 at 12:38:52 PM UTC+1, David Brown wrote:
>> On 30/08/16 12:32, Malcolm McLean wrote:
>>> On Tuesday, August 30, 2016 at 10:47:58 AM UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>> <snip>
>>>>> When I actually did this sort of thing.
>>>>>
>>>>> volatile char flag = 0;
>>>>>
>>>>> if(flag == 0)
>>>>> {
>>>>> flag = 1;
>>>>> do_your_stuff();
>>>>> flag = 0;
>>>>> }
>>>>>
>>>>> was fine. You could run as many threads as you wanted.
>>>>
>>>> Not, I hope, in a pacemaker -- there is nothing to prevent two threads
>>>> seeing flag == 0.
>>>>
>>>> You've spoken before about games programming and the idea that getting
>>>> incorrect results quickly is sometimes desirable. That may have been
>>>> the context where you actually did this sort of thing -- where a
>>>> violation of mutual exclusion might won't be a critical failure -- but
>>>> I'd always want to announce that about such code.
>>>>
>>> The interrupt occurs between the if() and the flag = 1?
>>
>> You said specifically "you could run as many threads as you wanted".
>> That's a very different situation from a background task synchronising
>> with an interrupt task.
>>
> Yes, the way it used to work way you had threads which yielded at various points.
> So if a thread yielded, another thread would take over. But a thread couldn't be
> interrupted to start another thread, unless in yield().
> Then the interrupt service routines could break in any time.
No, that is not how "threads used to work". That is how a /cooperative/
multi-tasking system works, which is a very specific type of task
scheduler. And again, the limitations of such a system means that as
long as everyone plays by the rules, synchronisation and locking can be
simpler than in a pre-emptive system.
Such cooperative multi-tasking was how old Windows and old Macs worked,
before they moved to pre-emptive multi-tasking. But many other systems
using pre-emptive multi-tasking long before that - and some modern
embedded systems have cooperative multi-tasking rather than pre-emptive
systems (because they are simpler).
So again, if you mean such a system, say so - or else when you talk
about "threads" people will assume the more common and more general case.
>>
>> Such reasoning can often be valid for the case of interrupts, because
>> the interrupt can break into the main thread, but not vice versa, and
>> because the interrupt function runs to completion before the main thread
>> regains control. This lets you use much simpler locking and
>> synchronisation mechanisms than general pre-emptive multi-threading.
>>
>> But if you are limiting yourself to just interrupts, then please say so
>> - don't say "threads".
>>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-30 18:55 +0100 |
| Message-ID | <87k2eyw38x.fsf@bsb.me.uk> |
| In reply to | #92932 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, August 30, 2016 at 10:47:58 AM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> <snip>
>> > When I actually did this sort of thing.
>> >
>> > volatile char flag = 0;
>> >
>> > if(flag == 0)
>> > {
>> > flag = 1;
>> > do_your_stuff();
>> > flag = 0;
>> > }
>> >
>> > was fine. You could run as many threads as you wanted.
>>
>> Not, I hope, in a pacemaker -- there is nothing to prevent two threads
>> seeing flag == 0.
>>
>> You've spoken before about games programming and the idea that getting
>> incorrect results quickly is sometimes desirable. That may have been
>> the context where you actually did this sort of thing -- where a
>> violation of mutual exclusion might won't be a critical failure -- but
>> I'd always want to announce that about such code.
>>
> The interrupt occurs between the if() and the flag = 1?
No, I was not assuming any particular model of threading.
> The thing is the interrupt routine disables interrupts. So the thread sees 0.
> The interrupt routine interrupts at that point, and also sees zero. the
> interrupt routine then does its stuff and plays about with buffer. Control
> returns to the main thread. The flag is now set to one. The main thread
> then plays about with the buffer. There's another interrupt, but now the
> flag is one, so the interrupt routine doesn't fiddle about with the buffer
> but does its stuff in a secondary or reserve buffer. main thread sets the
> flag to zero. theres a third interrupt, and now the interrupt routine does its
> stuff.
That does not match the usual meaning of "You could run as many threads
as you wanted". That suggests the flag provides mutual exclusion
between identical thread all running that code fragment. I'm happy that
the code worked in whatever environment you are describing. I just
wanted to make sure no one thought this was a general solution to mutual
exclusion between threads sharing memory.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-30 12:24 -0700 |
| Message-ID | <11e7b651-d17a-42bc-9044-7832975b72cb@googlegroups.com> |
| In reply to | #92954 |
On Tuesday, August 30, 2016 at 6:55:36 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Tuesday, August 30, 2016 at 10:47:58 AM UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >> <snip>
> >> > When I actually did this sort of thing.
> >> >
> >> > volatile char flag = 0;
> >> >
> >> > if(flag == 0)
> >> > {
> >> > flag = 1;
> >> > do_your_stuff();
> >> > flag = 0;
> >> > }
> >> >
> >> > was fine. You could run as many threads as you wanted.
> >>
> >> Not, I hope, in a pacemaker -- there is nothing to prevent two threads
> >> seeing flag == 0.
> >>
> >> You've spoken before about games programming and the idea that getting
> >> incorrect results quickly is sometimes desirable. That may have been
> >> the context where you actually did this sort of thing -- where a
> >> violation of mutual exclusion might won't be a critical failure -- but
> >> I'd always want to announce that about such code.
> >>
> > The interrupt occurs between the if() and the flag = 1?
>
> No, I was not assuming any particular model of threading.
>
> > The thing is the interrupt routine disables interrupts. So the thread sees 0.
> > The interrupt routine interrupts at that point, and also sees zero. the
> > interrupt routine then does its stuff and plays about with buffer. Control
> > returns to the main thread. The flag is now set to one. The main thread
> > then plays about with the buffer. There's another interrupt, but now the
> > flag is one, so the interrupt routine doesn't fiddle about with the buffer
> > but does its stuff in a secondary or reserve buffer. main thread sets the
> > flag to zero. theres a third interrupt, and now the interrupt routine does its
> > stuff.
>
> That does not match the usual meaning of "You could run as many threads
> as you wanted". That suggests the flag provides mutual exclusion
> between identical thread all running that code fragment. I'm happy that
> the code worked in whatever environment you are describing. I just
> wanted to make sure no one thought this was a general solution to mutual
> exclusion between threads sharing memory.
>
It was a general solution in that it worked.
It is apparently no longer, as I made clear.
[toc] | [prev] | [next] | [standalone]
| From | me <crisdunbar@gmail.com> |
|---|---|
| Date | 2016-08-30 14:11 -0700 |
| Message-ID | <cb808afe-de28-472f-b49c-26118b205416@googlegroups.com> |
| In reply to | #92957 |
On Tuesday, August 30, 2016 at 12:25:13 PM UTC-7, Malcolm McLean wrote:
> On Tuesday, August 30, 2016 at 6:55:36 PM UTC+1, Ben Bacarisse wrote:
> > Malcolm McLean <<elided>> writes:
> >
> > > On Tuesday, August 30, 2016 at 10:47:58 AM UTC+1, Ben Bacarisse wrote:
> > >> Malcolm McLean <<elided>> writes:
> > >> <snip>
> > >> > When I actually did this sort of thing.
> > >> >
> > >> > volatile char flag = 0;
> > >> >
> > >> > if(flag == 0)
> > >> > {
> > >> > flag = 1;
> > >> > do_your_stuff();
> > >> > flag = 0;
> > >> > }
> > >> >
> > >> > was fine. You could run as many threads as you wanted.
> > >>
> > >> Not, I hope, in a pacemaker -- there is nothing to prevent two threads
> > >> seeing flag == 0.
> > >>
> > >> You've spoken before about games programming and the idea that getting
> > >> incorrect results quickly is sometimes desirable. That may have been
> > >> the context where you actually did this sort of thing -- where a
> > >> violation of mutual exclusion might won't be a critical failure -- but
> > >> I'd always want to announce that about such code.
> > >>
> > > The interrupt occurs between the if() and the flag = 1?
> >
> > No, I was not assuming any particular model of threading.
> >
> > > The thing is the interrupt routine disables interrupts. So the thread sees 0.
> > > The interrupt routine interrupts at that point, and also sees zero. the
> > > interrupt routine then does its stuff and plays about with buffer. Control
> > > returns to the main thread. The flag is now set to one. The main thread
> > > then plays about with the buffer. There's another interrupt, but now the
> > > flag is one, so the interrupt routine doesn't fiddle about with the buffer
> > > but does its stuff in a secondary or reserve buffer. main thread sets the
> > > flag to zero. theres a third interrupt, and now the interrupt routine does its
> > > stuff.
> >
> > That does not match the usual meaning of "You could run as many threads
> > as you wanted". That suggests the flag provides mutual exclusion
> > between identical thread all running that code fragment. I'm happy that
> > the code worked in whatever environment you are describing. I just
> > wanted to make sure no one thought this was a general solution to mutual
> > exclusion between threads sharing memory.
> >
> It was a general solution in that it worked.
> It is apparently no longer, as I made clear.
First of all, "it worked [in one particular situation]" is hardly evidence
that it's a general solution. And since you called it a general solution
without qualification, you definitely did not make clear that it is no
longer [a solution?].
And I can't figure out what you think it's a solution to anyway. As Ben
pointed out, it's completely useless if two threads are using that
snippet to synchronize access to shared memory. Even in your restricted
context, I _think_ you're suggesting that the snippet is run in an ISR,
is therefore itself non-interruptible, and so there is no possibility of
context-switching between the 'if' and setting the flag. But in that case
there isn't any possibility of context-switching before the processing
either, or before clearing the flag, so why set and clear the flag
at all??
Can you clarify: is your snippet the bit that is run in the context of
a non-interruptible interrupt routine?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-30 16:28 -0700 |
| Message-ID | <81bfc1dc-2440-4816-81e8-dfd5585626d7@googlegroups.com> |
| In reply to | #92962 |
On Tuesday, August 30, 2016 at 10:11:11 PM UTC+1, me wrote: > > And I can't figure out what you think it's a solution to anyway. As Ben > pointed out, it's completely useless if two threads are using that > snippet to synchronize access to shared memory. Even in your restricted > context, I _think_ you're suggesting that the snippet is run in an ISR, > is therefore itself non-interruptible, and so there is no possibility of > context-switching between the 'if' and setting the flag. But in that case > there isn't any possibility of context-switching before the processing > either, or before clearing the flag, so why set and clear the flag > at all?? > > Can you clarify: is your snippet the bit that is run in the context of > a non-interruptible interrupt routine? > It can be run from both. The interrupt doesn't need to set the flag, strictly, because it will never be interrupted. But if there's some bug, it's maybe better to have the flag set to make that explict. The user thread doesn't need to read the flag, strictly, since it will always be clear, and it's unlikely that you will yield during a buffer update if there are lots of threads. But if you do it, the same code can be called by both.
[toc] | [prev] | [next] | [standalone]
| From | me <crisdunbar@gmail.com> |
|---|---|
| Date | 2016-08-30 16:54 -0700 |
| Message-ID | <82226170-a50a-4252-b0fc-abc5e4d66f74@googlegroups.com> |
| In reply to | #92969 |
On Tuesday, August 30, 2016 at 4:28:41 PM UTC-7, Malcolm McLean wrote: > On Tuesday, August 30, 2016 at 10:11:11 PM UTC+1, me wrote: > > > > And I can't figure out what you think it's a solution to anyway. As Ben > > pointed out, it's completely useless if two threads are using that > > snippet to synchronize access to shared memory. Even in your restricted > > context, I _think_ you're suggesting that the snippet is run in an ISR, > > is therefore itself non-interruptible, and so there is no possibility of > > context-switching between the 'if' and setting the flag. But in that case > > there isn't any possibility of context-switching before the processing > > either, or before clearing the flag, so why set and clear the flag > > at all?? > > > > Can you clarify: is your snippet the bit that is run in the context of > > a non-interruptible interrupt routine? > > > It can be run from both. > The interrupt doesn't need to set the flag, strictly, because it > will never be interrupted. But if there's some bug, it's maybe better > to have the flag set to make that explict. > The user thread doesn't need to read the flag, strictly, since it > will always be clear, and it's unlikely that you will yield during > a buffer update if there are lots of threads. > But if you do it, the same code can be called by both. That doesn't make any sense: the snippet can be run from both, but each has to do something different?? Anyway, if I ignore the inconsistencies in what you've said there, we still end up with a "synchronization" algorithm that works if: 1) We have an interruptible thread that's free to access the shared resource at any time it likes, so long as it sets the "busy" flag first. 2) We have a non-interruptible thread that occasionally checks that flag and if the flag is clear, the resource can be accessed. Can you explain a use-case for this type of thing?
[toc] | [prev] | [next] | [standalone]
Page 15 of 18 — ← Prev page 1 … 13 14 [15] 16 17 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web