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 10 of 18 — ← Prev page 1 … 8 9 [10] 11 12 … 18 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 04:08 -0700 |
| Message-ID | <4c14769d-f75d-4c8f-89f6-5290f6b97b32@googlegroups.com> |
| In reply to | #92714 |
On Friday, August 26, 2016 at 11:17:47 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > 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. But you can potentially have contention for the token - that's one detail. However you can use an expensive solution for that because getting the token is likely only a couple of machine instructions. We can say "freeze entire system except me" for a couple of instruction, but not for a long buffer write. The other problem is what to do if you are denied the token. Sometimes you can just busy idle until it come available again, but not always (eg if you hold a token from elsewhere in the program, you can potentially have a deadlock as two threads both busy idle until the token are exchanged). Then if, as is commonly the situation, data is coming from an external source and you need to put it in the buffer, what happens if another packet arrives whilst you are busy idling? It's not easy, but the basic flag or token concept is sound and is used in practiced. > > > Because you can only read from the buffer when it > > is in a coherent state. > > If this is not allowed, then it is deeply problematic for anyone > > using C for low-level, hardware interacting routines. > > C11 has atomic read/modify/write operations and various memory access > ordering primitives, but I think this thread grew out of a desire to > mange things with only minimal language support. If you don't have > these, you pretty much have to rely on other implementation-provided > mechanisms and guarantees. That's obviously what's going on in > supercat's example. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-26 13:45 +0100 |
| Message-ID | <87poovitqy.fsf@bsb.me.uk> |
| In reply to | #92715 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, August 26, 2016 at 11:17:47 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> 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. Yes, but the issue is how to take and release it. It's a well understood problem with well known solutions, I just got the feeling you were saying you could just use a shared "atomic" volatile object as the flag. (I'm sure you understand the problem, it's the impression you might give others that made me post.) > But you can potentially have contention for the token - that's one > detail. I though you might be including more than I would in the word "detail"! Ut's rather more than a detail in my book, but there's not much point in arguing over what is or is not a detail. <snip> >> C11 has atomic read/modify/write operations and various memory access >> ordering primitives, but I think this thread grew out of a desire to >> mange things with only minimal language support. If you don't have >> these, you pretty much have to rely on other implementation-provided >> mechanisms and guarantees. That's obviously what's going on in >> supercat's example. >> > People hooked up processors to IO ports that sent data at unpredictable > intervals long before 2011. Yes. These rely on implementation-defined guarantees. ,snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 06:09 -0700 |
| Message-ID | <62672946-dc1f-4d94-9c33-5434f51da85d@googlegroups.com> |
| In reply to | #92718 |
On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > 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. > > Yes, but the issue is how to take and release it. It's a well > understood problem with well known solutions, I just got the feeling you > were saying you could just use a shared "atomic" volatile object as the > flag. (I'm sure you understand the problem, it's the impression you > might give others that made me post.) > It's not something I do in practice very often. I was under the impression that if we declare a basic type volatile and, say, an interrupt serve routine also accesses it, the compiler is guaranteed to emit disable interrupts read variable enable interrupts if that's the only way of ensuring that you read a whole object, not one that is part written to. But I might be wrong on that. As I said, it's not something I actually do very often.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-26 17:11 +0100 |
| Message-ID | <87eg5bik7a.fsf@bsb.me.uk> |
| In reply to | #92720 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >> > 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. >> >> Yes, but the issue is how to take and release it. It's a well >> understood problem with well known solutions, I just got the feeling you >> were saying you could just use a shared "atomic" volatile object as the >> flag. (I'm sure you understand the problem, it's the impression you >> might give others that made me post.) >> > It's not something I do in practice very often. > I was under the impression that if we declare a basic type volatile and, > say, an interrupt serve routine also accesses it, the compiler is > guaranteed to emit > > disable interrupts > read variable > enable interrupts > > if that's the only way of ensuring that you read a whole object, not > one that is part written to. That's an unlikely translation (I've never seen it), but an implementation can do pretty much what it like with volatile accesses and so may well choose to do that. My point was about something else altogether: using a flag to synchronise threads, but that seems to have been buried now. > But I might be wrong on that. As I said, it's not something I actually > do very often. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 09:31 -0700 |
| Message-ID | <31200dba-21ba-40d6-8b12-a1b03a37dafb@googlegroups.com> |
| In reply to | #92735 |
On Friday, August 26, 2016 at 5:11:45 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>
> >
> >> > 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.
> >>
> >> Yes, but the issue is how to take and release it. It's a well
> >> understood problem with well known solutions, I just got the feeling you
> >> were saying you could just use a shared "atomic" volatile object as the
> >> flag. (I'm sure you understand the problem, it's the impression you
> >> might give others that made me post.)
> >>
> > It's not something I do in practice very often.
> > I was under the impression that if we declare a basic type volatile and,
> > say, an interrupt serve routine also accesses it, the compiler is
> > guaranteed to emit
> >
> > disable interrupts
> > read variable
> > enable interrupts
> >
> > if that's the only way of ensuring that you read a whole object, not
> > one that is part written to.
>
> That's an unlikely translation (I've never seen it), but an
> implementation can do pretty much what it like with volatile accesses
> and so may well choose to do that.
>
So you are saying that if we have this code
C
volatile counter = 0;
int prevecounter;
if(counter > prevcounter)
{
prevcounter = counter;
do_something();
}
ISR (assembly )
load byte (counter low) into accumlator
increment acumulator
write byte (counter low) from accumlator
if accumulator != 0
return from interrupt
load byte (counter high) into accumulator
increment accumulator
write byte (counter high) from accumulator
return from interrupt
then every so often we'll hit the point where
the counter is in the state low byte = zero, high byte =
previous high, and fail catastrophically?
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-26 12:48 -0400 |
| Message-ID | <npprsf$eu6$1@jstuckle.eternal-september.org> |
| In reply to | #92740 |
On 8/26/2016 12:31 PM, Malcolm McLean wrote:
> On Friday, August 26, 2016 at 5:11:45 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>
>>>
>>>>> 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.
>>>>
>>>> Yes, but the issue is how to take and release it. It's a well
>>>> understood problem with well known solutions, I just got the feeling you
>>>> were saying you could just use a shared "atomic" volatile object as the
>>>> flag. (I'm sure you understand the problem, it's the impression you
>>>> might give others that made me post.)
>>>>
>>> It's not something I do in practice very often.
>>> I was under the impression that if we declare a basic type volatile and,
>>> say, an interrupt serve routine also accesses it, the compiler is
>>> guaranteed to emit
>>>
>>> disable interrupts
>>> read variable
>>> enable interrupts
>>>
>>> if that's the only way of ensuring that you read a whole object, not
>>> one that is part written to.
>>
>> That's an unlikely translation (I've never seen it), but an
>> implementation can do pretty much what it like with volatile accesses
>> and so may well choose to do that.
>>
> So you are saying that if we have this code
>
> C
>
> volatile counter = 0;
> int prevecounter;
>
> if(counter > prevcounter)
> {
> prevcounter = counter;
> do_something();
> }
>
> ISR (assembly )
>
> load byte (counter low) into accumlator
> increment acumulator
> write byte (counter low) from accumlator
> if accumulator != 0
> return from interrupt
> load byte (counter high) into accumulator
> increment accumulator
> write byte (counter high) from accumulator
> return from interrupt
>
> then every so often we'll hit the point where
> the counter is in the state low byte = zero, high byte =
> previous high, and fail catastrophically?
>
It is possible, if it takes more than one assembler instruction to
access the two bytes. A small window, to be sure. But it does exist.
And user-space programs cannot disable interrupts.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-26 09:50 -0700 |
| Message-ID | <31fbd8a9-3ef3-4475-96b6-f5d84cc8c423@googlegroups.com> |
| In reply to | #92740 |
On Friday, August 26, 2016 at 11:31:35 AM UTC-5, Malcolm McLean wrote:
> So you are saying that if we have this code
>
> C
>
> volatile counter = 0;
> int prevecounter;
>
> if(counter > prevcounter)
> {
> prevcounter = counter;
> do_something();
> }
>
> ISR (assembly )
>
> load byte (counter low) into accumlator
> increment acumulator
> write byte (counter low) from accumlator
> if accumulator != 0
> return from interrupt
> load byte (counter high) into accumulator
> increment accumulator
> write byte (counter high) from accumulator
> return from interrupt
>
> then every so often we'll hit the point where
> the counter is in the state low byte = zero, high byte =
> previous high, and fail catastrophically?
On 8-bit platforms such failures would be commonplace. If one wants a
reliable 16-bit counter on an 8-bit platform, one would need to use some
mechanism to ensure validity, either by disabling interrupts when writing
it, or by doing something like:
int sampled_counter;
do
{
sampled_counter = counter;
} while (sampled_counter != counter);
The question is what should be guaranteed about the code:
unsigned char foo;
volatile unsigned char bar;
MAINLINE:
foo=0;
for (int i=0; i<=10; i++)
foo += i;
bar=1;
while(bar);
foo++;
INTERRUPT:
if (bar)
{
SOME_IO_PORT = foo;
foo++;
bar=0;
}
If a compiler guarantees that even without a volatile qualifier on "foo",
the volatile qualifier on "bar" will force it to store the value "55"
into "foo" before it writes "bar", and leave that value there until "bar"
reads zero, then it will only be necessary to write "foo" twice in the
main line and read it once (write 55, read 56, write 57). If the only
way to guarantee correct behavior would be to add a "volatile" qualifier
to "foo" as well as "bar", that would force the compiler to generate code
for the mainline that writes bar 12 times and reads it 11 times--not
nearly as efficient.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-29 16:01 +0200 |
| Message-ID | <nq1f7t$vgs$1@dont-email.me> |
| In reply to | #92744 |
On 26/08/16 18:50, supercat@casperkitty.com wrote:
> On Friday, August 26, 2016 at 11:31:35 AM UTC-5, Malcolm McLean wrote:
>> So you are saying that if we have this code
>>
>> C
>>
>> volatile counter = 0;
>> int prevecounter;
>>
>> if(counter > prevcounter)
>> {
>> prevcounter = counter;
>> do_something();
>> }
>>
>> ISR (assembly )
>>
>> load byte (counter low) into accumlator
>> increment acumulator
>> write byte (counter low) from accumlator
>> if accumulator != 0
>> return from interrupt
>> load byte (counter high) into accumulator
>> increment accumulator
>> write byte (counter high) from accumulator
>> return from interrupt
>>
>> then every so often we'll hit the point where
>> the counter is in the state low byte = zero, high byte =
>> previous high, and fail catastrophically?
>
> On 8-bit platforms such failures would be commonplace. If one wants a
> reliable 16-bit counter on an 8-bit platform, one would need to use some
> mechanism to ensure validity, either by disabling interrupts when writing
> it, or by doing something like:
>
> int sampled_counter;
> do
> {
> sampled_counter = counter;
> } while (sampled_counter != counter);
>
> The question is what should be guaranteed about the code:
>
> unsigned char foo;
> volatile unsigned char bar;
>
> MAINLINE:
> foo=0;
> for (int i=0; i<=10; i++)
> foo += i;
> bar=1;
> while(bar);
> foo++;
>
> INTERRUPT:
> if (bar)
> {
> SOME_IO_PORT = foo;
> foo++;
> bar=0;
> }
>
> If a compiler guarantees that even without a volatile qualifier on "foo",
> the volatile qualifier on "bar" will force it to store the value "55"
> into "foo" before it writes "bar", and leave that value there until "bar"
> reads zero, then it will only be necessary to write "foo" twice in the
> main line and read it once (write 55, read 56, write 57). If the only
> way to guarantee correct behavior would be to add a "volatile" qualifier
> to "foo" as well as "bar", that would force the compiler to generate code
> for the mainline that writes bar 12 times and reads it 11 times--not
> nearly as efficient.
>
The compiler is perfectly justified in turning "mainline" into:
bar = 1;
while (bar);
foo = 56;
That /is/ correct behaviour. It may not be the behaviour /you/ expect,
but it is perfectly good, correct behaviour for the code as written.
And no, it is /not/ the only way to get the behaviour you want (that foo
is set to 55 before bar is set to 1). There are many ways to achieve this.
You could use an implementation-specific memory barrier, such as the gcc
syntax (which also works on many other compilers):
unsigned char foo;
volatile unsigned char bar;
int test(void) {
foo = 0;
for (int i = 0; i <= 10; i++) foo += i;
asm("" ::: "memory");
bar = 1;
while (bar);
foo++;
return foo;
}
You could force a volatile write of foo (which is technically
implementation-dependent behaviour, I believe, but will work on any
system I have seen):
unsigned char foo;
volatile unsigned char bar;
int test(void) {
foo = 0;
for (int i = 0; i <= 10; i++) foo += i;
*(volatile unsigned char*) &foo = foo;
bar = 1;
while (bar);
foo++;
return foo;
}
You could make foo volatile, and use a non-volatile local for the
calculation:
volatile unsigned char foo;
volatile unsigned char bar;
int test(void) {
unsigned char ffoo = 0;
for (int i = 0; i <= 10; i++) ffoo += i;
foo = ffoo;
bar = 1;
while (bar);
foo++;
return foo;
}
There are /many/ ways to handle this situation correctly. There are
also many ways to handle it /incorrectly/ - such as believing your own
myths about how compilers /ought/ to behave, or how they /used/ to
behave, and spreading FUD and misinformation. This is an area of C
programming that is unfamiliar territory to many "big system"
programmers - what you write here simply confuses people.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-29 10:57 -0700 |
| Message-ID | <nq1t34$fif$1@dont-email.me> |
| In reply to | #92865 |
On 8/29/2016 7:01 AM, David Brown wrote:
[...]
> You could use an implementation-specific memory barrier, such as the gcc
> syntax (which also works on many other compilers):
>
> unsigned char foo;
> volatile unsigned char bar;
>
> int test(void) {
> foo = 0;
> for (int i = 0; i <= 10; i++) foo += i;
> asm("" ::: "memory");
> bar = 1;
> while (bar);
> foo++;
> return foo;
> }
Nit pick, but asm("" ::: "memory") is a compiler barrier. It does not
emit an actual memory barrier.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-08-31 06:09 +0000 |
| Message-ID | <slrn3vfsnsct5e.6jg.ike@iceland.freeshell.org> |
| In reply to | #92744 |
On 2016-08-26, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> The question is what should be guaranteed about the code:
>
> unsigned char foo;
> volatile unsigned char bar;
>
> MAINLINE:
> foo=0;
> for (int i=0; i<=10; i++)
> foo += i;
> bar=1;
> while(bar);
> foo++;
>
> INTERRUPT:
> if (bar)
> {
> SOME_IO_PORT = foo;
> foo++;
> bar=0;
> }
>
> If a compiler guarantees that even without a volatile qualifier on "foo",
> the volatile qualifier on "bar" will force it to store the value "55"
> into "foo" before it writes "bar",
An interrupt might occur before MAINLINE executes bar=1;
At that moment, the value of bar is indeterminate, if it's nonzero then
the body of the if block in INTERRUPT is executed, incrementing foo.
So it's not guaranteed that foo equals 55 when bar is written.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-26 12:24 -0700 |
| Message-ID | <npq50u$hc6$1@dont-email.me> |
| In reply to | #92740 |
On 8/26/2016 9:31 AM, Malcolm McLean wrote:
> On Friday, August 26, 2016 at 5:11:45 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>
>>>
>>>>> 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.
>>>>
>>>> Yes, but the issue is how to take and release it. It's a well
>>>> understood problem with well known solutions, I just got the feeling you
>>>> were saying you could just use a shared "atomic" volatile object as the
>>>> flag. (I'm sure you understand the problem, it's the impression you
>>>> might give others that made me post.)
>>>>
>>> It's not something I do in practice very often.
>>> I was under the impression that if we declare a basic type volatile and,
>>> say, an interrupt serve routine also accesses it, the compiler is
>>> guaranteed to emit
>>>
>>> disable interrupts
>>> read variable
>>> enable interrupts
>>>
>>> if that's the only way of ensuring that you read a whole object, not
>>> one that is part written to.
>>
>> That's an unlikely translation (I've never seen it), but an
>> implementation can do pretty much what it like with volatile accesses
>> and so may well choose to do that.
>>
> So you are saying that if we have this code
>
> C
>
> volatile counter = 0;
> int prevecounter;
>
> if(counter > prevcounter)
> {
> prevcounter = counter;
> do_something();
> }
>
> ISR (assembly )
>
> load byte (counter low) into accumlator
> increment acumulator
> write byte (counter low) from accumlator
> if accumulator != 0
> return from interrupt
> load byte (counter high) into accumulator
> increment accumulator
> write byte (counter high) from accumulator
> return from interrupt
>
> then every so often we'll hit the point where
> the counter is in the state low byte = zero, high byte =
> previous high, and fail catastrophically?
>
FWIW, clever use of atomic ops via lock/wait free algorithms, can
guarantee all of this works with interrupt handlers _and_ multiple threads.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-26 17:27 -0700 |
| Message-ID | <npqmq7$a9c$1@dont-email.me> |
| In reply to | #92753 |
On 8/26/2016 12:24 PM, Chris M. Thomasson wrote:
> On 8/26/2016 9:31 AM, Malcolm McLean wrote:
>> On Friday, August 26, 2016 at 5:11:45 PM UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>
>>>> On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>>
>>>>
>>>>>> 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.
>>>>>
>>>>> Yes, but the issue is how to take and release it. It's a well
>>>>> understood problem with well known solutions, I just got the
>>>>> feeling you
>>>>> were saying you could just use a shared "atomic" volatile object as
>>>>> the
>>>>> flag. (I'm sure you understand the problem, it's the impression you
>>>>> might give others that made me post.)
>>>>>
>>>> It's not something I do in practice very often.
>>>> I was under the impression that if we declare a basic type volatile
>>>> and,
>>>> say, an interrupt serve routine also accesses it, the compiler is
>>>> guaranteed to emit
>>>>
>>>> disable interrupts
>>>> read variable
>>>> enable interrupts
>>>>
>>>> if that's the only way of ensuring that you read a whole object, not
>>>> one that is part written to.
>>>
>>> That's an unlikely translation (I've never seen it), but an
>>> implementation can do pretty much what it like with volatile accesses
>>> and so may well choose to do that.
>>>
>> So you are saying that if we have this code
>>
>> C
>>
>> volatile counter = 0;
>> int prevecounter;
>>
>> if(counter > prevcounter)
>> {
>> prevcounter = counter;
>> do_something();
>> }
>>
>> ISR (assembly )
>>
>> load byte (counter low) into accumlator
>> increment acumulator
>> write byte (counter low) from accumlator
>> if accumulator != 0
>> return from interrupt
>> load byte (counter high) into accumulator
>> increment accumulator
>> write byte (counter high) from accumulator
>> return from interrupt
>>
>> then every so often we'll hit the point where
>> the counter is in the state low byte = zero, high byte =
>> previous high, and fail catastrophically?
>>
>
> FWIW, clever use of atomic ops via lock/wait free algorithms, can
> guarantee all of this works with interrupt handlers _and_ multiple threads.
Here is a simple example of something that works with threads and
interrupt handlers:
A dynamic atomic stack, without the ABA problem:
https://en.wikipedia.org/wiki/ABA_problem
quick pseudo code
_____________________________________________
struct node
{
struct node* next;
};
// Relaxed Memory Order
#define ALOAD(p) \
atomic_load_explicit((p), memory_order_relaxed)
#define ASTORE(p, n) \
atomic_store_explicit((p), (n), memory_order_relaxed)
#define AXCHG(p, n) \
atomic_exchange_explicit((p), (n), memory_order_relaxed)
#define ACAS(p, c, x) \
atomic_compare_exchange_weak( \
(p), (c), (x), memory_order_relaxed, memory_order_relaxed)
// Explicit memory and compiler barrier
#define MB(p) atomic_thread_fence((p))
static struct node* g_head = NULL;
// Producer
void push(struct node* n)
{
struct node* h = ALOAD(&g_head);
do
{
0: ASTORE(&n->next, h);
// ensure visibility with consumer
MB(memory_order_release);
}
// keep in mind that C++/C11 CAS automatically
// updates the comparand, (h) in this case.
while (! ACAS(&g_head, &h, n));
}
// Consumer
struct node* flush()
{
1: struct node* h = AXCHG(&g_head, NULL);
// ensure visibility from the producer
MB(memory_order_acquire);
return h;
}
_____________________________________________
0 must be visible before 1; AXCHG acts as a load, but its relaxed. We
need the acquire barrier in the consumer to sync with the release
barrier in the producer. It is a simple rule that acquire/release
barriers satisfy. Also, this data-structure can safely be used in
interrupt handlers.
Its too bad that C11 threads are not implemented by a lot of compiler
packages. And by the way, IMVHO, being able to support
atomic_signal_fence should not imply that threading works. I can see a
single threaded app that just wants a standard damn compiler barrier wrt
an interrupt in C. It does not want any membars!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-08-26 17:39 -0700 |
| Message-ID | <npqnfb$bni$1@dont-email.me> |
| In reply to | #92772 |
On 8/26/2016 5:27 PM, Chris M. Thomasson wrote:
> On 8/26/2016 12:24 PM, Chris M. Thomasson wrote:
>> On 8/26/2016 9:31 AM, Malcolm McLean wrote:
>>> On Friday, August 26, 2016 at 5:11:45 PM UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>
>>>>> On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>>>
>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Yes, but the issue is how to take and release it. It's a well
>>>>>> understood problem with well known solutions, I just got the
>>>>>> feeling you
>>>>>> were saying you could just use a shared "atomic" volatile object as
>>>>>> the
>>>>>> flag. (I'm sure you understand the problem, it's the impression you
>>>>>> might give others that made me post.)
>>>>>>
>>>>> It's not something I do in practice very often.
>>>>> I was under the impression that if we declare a basic type volatile
>>>>> and,
>>>>> say, an interrupt serve routine also accesses it, the compiler is
>>>>> guaranteed to emit
>>>>>
>>>>> disable interrupts
>>>>> read variable
>>>>> enable interrupts
>>>>>
>>>>> if that's the only way of ensuring that you read a whole object, not
>>>>> one that is part written to.
>>>>
>>>> That's an unlikely translation (I've never seen it), but an
>>>> implementation can do pretty much what it like with volatile accesses
>>>> and so may well choose to do that.
>>>>
>>> So you are saying that if we have this code
>>>
>>> C
>>>
>>> volatile counter = 0;
>>> int prevecounter;
>>>
>>> if(counter > prevcounter)
>>> {
>>> prevcounter = counter;
>>> do_something();
>>> }
>>>
>>> ISR (assembly )
>>>
>>> load byte (counter low) into accumlator
>>> increment acumulator
>>> write byte (counter low) from accumlator
>>> if accumulator != 0
>>> return from interrupt
>>> load byte (counter high) into accumulator
>>> increment accumulator
>>> write byte (counter high) from accumulator
>>> return from interrupt
>>>
>>> then every so often we'll hit the point where
>>> the counter is in the state low byte = zero, high byte =
>>> previous high, and fail catastrophically?
>>>
>>
>> FWIW, clever use of atomic ops via lock/wait free algorithms, can
>> guarantee all of this works with interrupt handlers _and_ multiple
>> threads.
>
> Here is a simple example of something that works with threads and
> interrupt handlers:
>
> A dynamic atomic stack, without the ABA problem:
>
> https://en.wikipedia.org/wiki/ABA_problem
>
>
> quick pseudo code
> _____________________________________________
> struct node
> {
> struct node* next;
> };
>
>
> // Relaxed Memory Order
> #define ALOAD(p) \
> atomic_load_explicit((p), memory_order_relaxed)
>
> #define ASTORE(p, n) \
> atomic_store_explicit((p), (n), memory_order_relaxed)
>
> #define AXCHG(p, n) \
> atomic_exchange_explicit((p), (n), memory_order_relaxed)
>
> #define ACAS(p, c, x) \
> atomic_compare_exchange_weak( \
> (p), (c), (x), memory_order_relaxed, memory_order_relaxed)
See, I already found a mistake in ACAS... It needs to use the explicit
version of the damn CAS function!
atomic_compare_exchange_weak_explicit
#define ACAS(p, c, x) \
atomic_compare_exchange_weak_explicit( \
(p), (c), (x), memory_order_relaxed, memory_order_relaxed)
Sorry about that! I cannot compile standard C11 atomics yet, so its hard
to find some errors. I could mock something up; have no real need for it
because c++ compilers already have great threading support. But, I can
create a C++ layer for atomics and membars and present it as a C API.
Then construct a C11 layer on top of said C API. I already have done
some of the actual threading C11 API's, using POSIX threads as a base:
https://groups.google.com/d/topic/comp.lang.c/WPH7ed5uS4Y/discussion
All this needs is the atomics and membar C11 API's, then it should work
nice.
;^)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-26 21:49 +0100 |
| Message-ID | <87wpj3gssb.fsf@bsb.me.uk> |
| In reply to | #92740 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, August 26, 2016 at 5:11:45 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >>
>> >
>> >> > 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.
>> >>
>> >> Yes, but the issue is how to take and release it. It's a well
>> >> understood problem with well known solutions, I just got the feeling you
>> >> were saying you could just use a shared "atomic" volatile object as the
>> >> flag. (I'm sure you understand the problem, it's the impression you
>> >> might give others that made me post.)
>> >>
>> > It's not something I do in practice very often.
>> > I was under the impression that if we declare a basic type volatile and,
>> > say, an interrupt serve routine also accesses it, the compiler is
>> > guaranteed to emit
>> >
>> > disable interrupts
>> > read variable
>> > enable interrupts
>> >
>> > if that's the only way of ensuring that you read a whole object, not
>> > one that is part written to.
>>
>> That's an unlikely translation (I've never seen it), but an
>> implementation can do pretty much what it like with volatile accesses
>> and so may well choose to do that.
>>
> So you are saying that if we have this code
>
> C
>
> volatile counter = 0;
(Implicit int declarations are no longer permitted.)
> int prevecounter;
>
> if(counter > prevcounter)
> {
> prevcounter = counter;
> do_something();
> }
(A few ...s helps with code like this. Currently what you have is UB
due to the use of an indeterminate value.)
> ISR (assembly )
>
> load byte (counter low) into accumlator
> increment acumulator
> write byte (counter low) from accumlator
> if accumulator != 0
> return from interrupt
> load byte (counter high) into accumulator
> increment accumulator
> write byte (counter high) from accumulator
> return from interrupt
>
> then every so often we'll hit the point where
> the counter is in the state low byte = zero, high byte =
> previous high, and fail catastrophically?
Yes, but I'm saying much more. Other than issue the required
diagnostics about type conversion and so on, a compiler is even allowed
to ignore the volatile qualifier in the sense that it need take no
special action based on it, and the memory system can behave in odder
ways than your example assembly. It's all up for grabs.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-29 15:51 +0200 |
| Message-ID | <nq1ekh$sfv$1@dont-email.me> |
| In reply to | #92740 |
On 26/08/16 18:31, Malcolm McLean wrote:
> On Friday, August 26, 2016 at 5:11:45 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>>
>>>
>>>>> 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.
>>>>
>>>> Yes, but the issue is how to take and release it. It's a well
>>>> understood problem with well known solutions, I just got the feeling you
>>>> were saying you could just use a shared "atomic" volatile object as the
>>>> flag. (I'm sure you understand the problem, it's the impression you
>>>> might give others that made me post.)
>>>>
>>> It's not something I do in practice very often.
>>> I was under the impression that if we declare a basic type volatile and,
>>> say, an interrupt serve routine also accesses it, the compiler is
>>> guaranteed to emit
>>>
>>> disable interrupts
>>> read variable
>>> enable interrupts
>>>
>>> if that's the only way of ensuring that you read a whole object, not
>>> one that is part written to.
>>
>> That's an unlikely translation (I've never seen it), but an
>> implementation can do pretty much what it like with volatile accesses
>> and so may well choose to do that.
>>
> So you are saying that if we have this code
>
> C
>
> volatile counter = 0;
> int prevecounter;
>
> if(counter > prevcounter)
> {
> prevcounter = counter;
> do_something();
> }
>
> ISR (assembly )
>
> load byte (counter low) into accumlator
> increment acumulator
> write byte (counter low) from accumlator
> if accumulator != 0
> return from interrupt
> load byte (counter high) into accumulator
> increment accumulator
> write byte (counter high) from accumulator
> return from interrupt
>
> then every so often we'll hit the point where
> the counter is in the state low byte = zero, high byte =
> previous high, and fail catastrophically?
>
If reading "counter" takes more than one instruction (because "int" is
wider than the cpu width), then the interrupt could occur between
reading the two halves of "counter".
Declaring something as "volatile" does /not/ make it atomic. Declaring
it as _Atomic (in C11) makes it atomic. Or, pre-C11, you implement safe
atomic accesses yourself. There are many ways to do this - the "best"
way depends on the circumstances.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-29 15:46 +0200 |
| Message-ID | <nq1ec8$qvk$2@dont-email.me> |
| In reply to | #92735 |
On 26/08/16 18:11, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> >> >>>> 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. >>> >>> Yes, but the issue is how to take and release it. It's a well >>> understood problem with well known solutions, I just got the feeling you >>> were saying you could just use a shared "atomic" volatile object as the >>> flag. (I'm sure you understand the problem, it's the impression you >>> might give others that made me post.) >>> >> It's not something I do in practice very often. >> I was under the impression that if we declare a basic type volatile and, >> say, an interrupt serve routine also accesses it, the compiler is >> guaranteed to emit >> >> disable interrupts >> read variable >> enable interrupts >> >> if that's the only way of ensuring that you read a whole object, not >> one that is part written to. > > That's an unlikely translation (I've never seen it), but an > implementation can do pretty much what it like with volatile accesses > and so may well choose to do that. > It is not a translation any compiler would make for volatile accesses, but an implementation might make a similar sequence for /atomic/ accesses: disable interrupts, preserving old status access /atomic/ variable restore interrupts to their previous status Malcolm is confused about the meanings of "volatile" and "atomic". > My point was about something else altogether: using a flag to > synchronise threads, but that seems to have been buried now. > >> But I might be wrong on that. As I said, it's not something I actually >> do very often. >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-08-26 17:37 -0400 |
| Message-ID | <eE2wz.36092$1b1.31741@fx43.iad> |
| In reply to | #92720 |
On 8/26/16 9:09 AM, Malcolm McLean wrote: > On Friday, August 26, 2016 at 1:45:35 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >>> 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. >> >> Yes, but the issue is how to take and release it. It's a well >> understood problem with well known solutions, I just got the feeling you >> were saying you could just use a shared "atomic" volatile object as the >> flag. (I'm sure you understand the problem, it's the impression you >> might give others that made me post.) >> > It's not something I do in practice very often. > I was under the impression that if we declare a basic type volatile and, > say, an interrupt serve routine also accesses it, the compiler is > guaranteed to emit > > disable interrupts > read variable > enable interrupts > > if that's the only way of ensuring that you read a whole object, not > one that is part written to. > > But I might be wrong on that. As I said, it's not something I actually > do very often. > > > volatile only requires that the compiler reads the variable exactly once for every read mention and writes exactly once for every assignment in the code. They also need to be ordered based on the promises of the abstract machine. It does not guarantee atomic access. For that you need to use things with atomic guarantees.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-26 15:05 -0700 |
| Message-ID | <71637eed-ce54-4950-9568-d053ff0abc84@googlegroups.com> |
| In reply to | #92764 |
On Friday, August 26, 2016 at 4:37:23 PM UTC-5, Richard Damon wrote: > volatile only requires that the compiler reads the variable exactly once > for every read mention and writes exactly once for every assignment in > the code. They also need to be ordered based on the promises of the > abstract machine. It does not guarantee atomic access. For that you need > to use things with atomic guarantees. It is often reasonable for an implementation to limit its guarantees to those the hardware would provide on a "normal" access. That does not imply that programmers should not be entitled to expect that *quality* implementations will provide guarantees at least as strong as those of the underlying hardware unless there is an obviously-compelling reason to do so.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-27 10:25 +1200 |
| Message-ID | <e2bttuFa03jU6@mid.individual.net> |
| In reply to | #92765 |
On 08/27/16 10:05 AM, supercat@casperkitty.com wrote: > On Friday, August 26, 2016 at 4:37:23 PM UTC-5, Richard Damon wrote: >> volatile only requires that the compiler reads the variable exactly once >> for every read mention and writes exactly once for every assignment in >> the code. They also need to be ordered based on the promises of the >> abstract machine. It does not guarantee atomic access. For that you need >> to use things with atomic guarantees. > > It is often reasonable for an implementation to limit its guarantees to > those the hardware would provide on a "normal" access. That does not > imply that programmers should not be entitled to expect that *quality* > implementations will provide guarantees at least as strong as those of > the underlying hardware unless there is an obviously-compelling reason > to do so. It would still be foolhardy to rely on such an assumption. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-26 16:25 -0700 |
| Message-ID | <3717aec1-a74c-4489-9a61-47245e8d0b08@googlegroups.com> |
| In reply to | #92767 |
On Friday, August 26, 2016 at 5:25:11 PM UTC-5, Ian Collins wrote:
> On 08/27/16 10:05 AM, supercat wrote:
> > It is often reasonable for an implementation to limit its guarantees to
> > those the hardware would provide on a "normal" access. That does not
> > imply that programmers should not be entitled to expect that *quality*
> > implementations will provide guarantees at least as strong as those of
> > the underlying hardware unless there is an obviously-compelling reason
> > to do so.
>
> It would still be foolhardy to rely on such an assumption.
It would be certainly foolhardy to assume that everything that claims
to be a quality compiler will behave in such fashion. As to whether a
compiler which fails to behave in such fashion without an obviously-
compelling reason (*) should be considered a "quality" compiler, that
would be a judgment call.
(*) A programmer's use of a directive or command-line option which
expressly waives particular guarantees would count as an
obviously-compelling reason for a compiler not to uphold them,
provided the documentation is clear about what is or is not being
waived.
[toc] | [prev] | [next] | [standalone]
Page 10 of 18 — ← Prev page 1 … 8 9 [10] 11 12 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web