Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #111126 > unrolled thread
| Started by | Robert Finch <robfi680@gmail.com> |
|---|---|
| First post | 2025-03-13 00:50 -0400 |
| Last post | 2025-03-17 17:33 -0400 |
| Articles | 20 on this page of 211 — 12 participants |
Back to article view | Back to comp.arch
MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 00:50 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 16:34 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 13:49 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 18:42 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 15:59 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 20:46 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:39 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 17:00 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:27 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:27 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 19:12 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 18:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 19:28 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:14 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 21:34 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 23:52 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 14:52 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 15:34 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 17:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 18:12 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 18:42 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-14 22:10 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-15 17:46 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-15 16:46 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-15 22:28 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-16 17:35 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-16 22:00 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 13:38 +0000
Re: MSI interrupts Michael S <already5chosen@yahoo.com> - 2025-03-17 16:11 +0200
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 11:23 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 15:44 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-17 14:33 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 17:14 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-18 14:51 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 17:59 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 23:00 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 13:49 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:54 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 16:14 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 19:03 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-19 14:03 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:59 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 12:44 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 19:41 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 20:25 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 21:55 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 12:37 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 13:59 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 17:47 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:49 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 12:12 -0700
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 19:46 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:14 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:02 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:05 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:17 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:14 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 13:32 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 17:36 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-24 14:02 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 19:09 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:28 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 22:29 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 23:27 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 13:43 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 15:08 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 11:48 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 16:29 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 13:28 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-25 13:53 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 20:33 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:47 +0000
Re: MSI interrupts Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-27 10:55 +0100
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 20:31 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:08 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:20 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 13:38 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 22:21 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 16:23 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 23:29 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 16:53 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:55 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-24 13:46 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 12:09 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:11 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 22:50 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 23:45 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 01:53 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 01:26 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 00:07 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 12:23 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 13:45 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 15:01 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 15:10 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 16:40 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:54 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 20:40 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 22:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 18:49 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 23:33 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 22:58 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 04:40 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 19:42 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 09:17 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-27 13:42 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 17:09 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 01:00 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 00:56 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 04:08 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 09:55 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 14:57 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-26 13:22 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-03 22:19 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 19:21 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 15:41 -0400
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 15:50 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 23:16 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-26 21:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 23:22 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-26 23:48 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 00:18 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 12:46 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 17:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 14:27 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 18:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 19:18 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 01:01 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 01:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 01:47 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 22:02 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:14 -0700
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-29 10:31 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:56 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 21:52 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:58 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:09 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:10 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 21:47 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:53 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 15:24 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-28 11:41 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-28 09:51 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 14:28 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-29 15:23 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 20:58 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-29 22:04 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-25 10:54 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 16:31 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:44 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-28 14:40 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 20:55 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-30 16:34 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-31 03:33 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-31 01:30 -0400
Software synchronization (was: Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-31 14:42 +0000
Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-03-31 15:28 +0000
Re: Threads (was Re: MSI interrupts) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-04-01 16:44 +0200
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 15:31 +0000
Re: Threads (was Re: MSI interrupts) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 12:49 -0700
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 20:01 +0000
Re: Threads (was Re: MSI interrupts) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 13:17 -0700
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 22:04 +0000
Re: Threads (was Re: MSI interrupts) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-02 06:25 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-02 13:04 +0000
Re: Threads (was Re: MSI interrupts) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-04-03 16:45 +0200
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 15:00 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-03 17:16 +0000
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 17:24 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-04 01:44 +0000
Centronics (was Re: Threads (was Re: MSI interrupts)) George Neuner <gneuner2@comcast.net> - 2025-04-03 22:22 -0400
Re: Centronics (was Re: Threads (was Re: MSI interrupts)) scott@slp53.sl.home (Scott Lurndal) - 2025-04-04 02:29 +0000
Re: Threads (was Re: MSI interrupts) George Neuner <gneuner2@comcast.net> - 2025-04-03 01:38 -0400
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-03 12:15 +0000
Re: Threads (was Re: MSI interrupts) Robert Swindells <rjs@fdy2.co.uk> - 2025-04-04 10:41 +0000
Re: Threads (was Re: MSI interrupts) George Neuner <gneuner2@comcast.net> - 2025-04-04 23:10 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-01 10:07 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-01 17:39 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 23:28 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 12:50 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 22:28 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-23 12:16 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-23 16:48 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-24 11:55 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 18:56 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-23 17:48 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:39 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-20 12:03 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 19:52 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-19 13:07 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-19 15:47 -0400
Re: MSI interrupts - Instructions Robert Finch <robfi680@gmail.com> - 2025-03-26 06:56 -0400
Re: MSI interrupts - Instructions EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-26 10:33 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 22:49 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 20:39 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 01:22 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 23:22 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 13:54 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:56 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-17 21:49 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-18 01:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 18:51 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 19:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-19 11:20 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 16:00 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-19 13:27 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 19:17 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 10:12 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 15:53 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-17 19:06 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 17:33 -0400
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 23:29 +0000 |
| Message-ID | <vrve8r$fv9$1@reader1.panix.com> |
| In reply to | #111317 |
In article <vrvdth$d24n$1@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 3/25/2025 3:21 PM, Dan Cross wrote: >> In article <vrv483$3ekk$2@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 3/25/2025 4:20 AM, Dan Cross wrote: >>>> In article <vrt37r$27c13$4@dont-email.me>, >>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> On 3/24/2025 1:28 PM, Dan Cross wrote: >>>>>> There's no guarantee that the tail is the correct place to >>>>>> insert the element, vis the order of the elements. >>>>> >>>>> https://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html >>>> >>>> If you go back and review the thread, you'd see that the problem >>>> is to remove an element from a queue, and insert it into an >>>> ordered list. This part of the discussion is concerning the >>>> latter operation. >>> >>> There are lock-free ways to insert into an ordered list, indeed. >> >> How is that relevant? > >inserting into an ordered list is not relevant? The fact that you can use a lock-free algorithm to do so seems utterly beside the point. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-25 16:53 -0700 |
| Message-ID | <vrvfmg$d24n$2@dont-email.me> |
| In reply to | #111318 |
On 3/25/2025 4:29 PM, Dan Cross wrote: > In article <vrvdth$d24n$1@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 3/25/2025 3:21 PM, Dan Cross wrote: >>> In article <vrv483$3ekk$2@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 3/25/2025 4:20 AM, Dan Cross wrote: >>>>> In article <vrt37r$27c13$4@dont-email.me>, >>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>>> On 3/24/2025 1:28 PM, Dan Cross wrote: >>>>>>> There's no guarantee that the tail is the correct place to >>>>>>> insert the element, vis the order of the elements. >>>>>> >>>>>> https://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html >>>>> >>>>> If you go back and review the thread, you'd see that the problem >>>>> is to remove an element from a queue, and insert it into an >>>>> ordered list. This part of the discussion is concerning the >>>>> latter operation. >>>> >>>> There are lock-free ways to insert into an ordered list, indeed. >>> >>> How is that relevant? >> >> inserting into an ordered list is not relevant? > > The fact that you can use a lock-free algorithm to do so seems > utterly beside the point. So be it.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-24 18:55 +0000 |
| Message-ID | <vrs9r3$pnb$3@reader1.panix.com> |
| In reply to | #111265 |
In article <33d525dc9450a654173f9313f0564224@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>On Mon, 24 Mar 2025 12:37:13 +0000, Dan Cross wrote:
>> In article <4603ec2d5082f16ab0588b4b9d6f96c7@www.novabbs.org>,
>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>---------------------
>>>My architecture has a mechanism to perform ATOMIC stuff over multiple
>>>instruction time frames that has the property that a higher priority
>>>thread which interferers with a lower priority thread, the HPT wins
>>>and the LPT fails its ATOMIC event. It is for exactly this reason
>>>that I drag priority through the memory hierarchy--so that real-time
>>>things remain closer to real-time (no or limited priority inversions).
>>
>> Without being able to see this in practice, it's difficult to
>> speculate as to how well it will actually work in real-world
>> scenarios. What is the scope of what's covered by this atomic
>> thing?
>>
>> Consider something as simple as popping an item off of the front
>> of a queue and inserting it into an ordered singly-linked list:
>> In this case, I'm probably going to want to take a lock on the
>> queue, then lock the list, then pop the first element off of the
>> queue by taking a pointer to the head. Then I'll set the head
>> to the next element of that item, then walk the list, finding
>> the place to insert (make sure I'm keeping track of the "prev"
>> pointer somehow), then do the dance to insert the item: set the
>> item's next to the thing after where I'm inserting, set the
>> prev's next to the item if it's not nil, or set the list head
>> to the item. Then I unlock the list and then the queue (suppose
>> for some reason that it's important that I hold the lock on the
>> queue until the element is fully added to the list).
>
>I have almost that in the documentation for my ATOMIC stuff::
>The following code moves a doubly linked element from one place
>in a concurrent data structure to another without any interested
>3rd party being able to see that the element is now within the
>CDS at any time::
>
>BOOLEAN MoveElement( Element *fr, Element *to )
>{
> Element *fn = esmLOCKload( fr->next );
> Element *fp = esmLOCKload( fr->prev );
> Element *tn = esmLOCKload( to->next );
> esmLOCKprefetch( fn );
> esmLOCKprefetch( fp );
> esmLOCKprefetch( tn );
> if( !esmINTERFERENCE() )
> {
> fp->next = fn;
> fn->prev = fp;
> to->next = fr;
> tn->prev = fr;
> fr->prev = to;
> esmLOCKstore( fr->next, tn );
> return TRUE;
> }
> return FALSE;
>}
>
>The ESM macros simply tell the compiler to set a bit in the LD/ST
>instructions. esmINTERFERENCE is a query on the state of the event
>and whether a 2nd party has performed a memory action that kills
>the event.
>
>It is required to touch every cache line participating in the event
>prior to attempting the ATOMIC update--this is what esmLOCKprefetch
>does. One can use up to 8 cache lines in a single ATOMIC event.
>
>Either everyone in the system sees the update and at the same
>instant in time, or no one sees any update at all.
>
>Technically, there is no one holding a lock ...
Suppose I need to get the first two elements of the list.
>> This isn't complicated, and for a relatively small list it's not
>> expensive. Depending on the circumstances, I'd feel comfortable
>> doing this with only a spinlocks protecting both the queue and
>> the list. But it's more than a two or three instructions, and
>> doesn't feel like something that would fit well into the "may
>> fail atomic" model.
>
>Should be obvious how to change the insertion into a singly linked
>list in a different data structure.
>
>>>Mandating to SW that typ SW must use this mechanism will not fly,
>>>at least in the first several iterations of an OS for the system.
>>>So the std. methods must remain available.
>>>
>>>AND to a large extend this sub-thread is attempting to get a
>>>usefully large number of them annotated.
>>
>> It sounds like the whole model is fairly different, and would
>> require software writers to consider interrupts occuring in
>> places that wouldn't have to in a more conventional design. I
>> suspect you'd have a fairly serious porting issue with existing
>> systems, but maybe I misunderstand.
>
>Which is why ID is available.
>
>>>> A valid response here might be, "don't context switch from the
>>>> interrupt handler; use a DPC instead". That may be valid, but
>>>> it puts a constraint on the software designer that may be onerus
>>>> in practice: suppose the interrupt happens in the scheduler,
>>>> while examining a run queue or something. A DPC object must be
>>>> available, etc.
>>>
>>>This seems to be onerous on SW mainly because of too many unknowns
>>>to track down and deal with.
>>
>> Yes.
>>
>>>> Further, software must now consider the complexity of
>>>> potentially interruptable critical sections. From the
>>>> standpoint of reasoning about already-complex concurrency issues
>>>> it's simpler to be able to assert that (almost) all interrupt
>>>> delivery can be cheaply disabled entirely, save for very
>>>> special, specific, scenarios like NMIs. Potentially switching
>>>> away from a thread holding a spinlock sort of defeats the
>>>> purpose of a spinlock in the first place, which is a mutex
>>>> primitive designed to avoid the overhead of switching.
>>>
>>>Agreed.
>>
>> The idea of priority as described above seems to prize latency
>> above other considerations, but it's not clear to me that that
>> is the right tradeoff. Exactly what problem is being solved?
>
>The instruction path into and out of handlers is shorter. Basically
>nobody has to look at the schedule queues because HW will do it for
>you. For example: GuestOS interrupt dispatcher is approximately::
>
>-- +-------------+-----+------------------------+
>R0 | ----------- | ISR | --- MSI-X message ---- |
>-- +-------------+-----+------------------------+
>
>Dispatcher:
> // at this point we are reentrant
> SR R7,R0,<39:32>
> CMP R2,R7,MaxTable
> PLO R2,TTTF
> SR R1,R0,<32:0>
> CALX [IP,R7<<3,Table-.]
> SVR
> // if we get here R0<37:32>
> // was out of bounds
>
>This does all of the register file saving and restoring, all of
>the DPC/softIRQ stuff, all of the checking for additional ISRs,
>IPIs, ... Changes priority, privilege, ROOT pointers and associated
>ASIDs from and back to.
But again, why is that important? Is that a significant
bottleneck for systems software? Is it particularly burdensome
for software for some reason?
I explicitly don't want the hardware to have that level of
control in my scheduling subsystem.
This sounds like a solution looking for a problem.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-24 13:46 -0400 |
| Message-ID | <kVgEP.1277108$_N6e.605199@fx17.iad> |
| In reply to | #111244 |
Dan Cross wrote: > In article <fe9715fa347144df1e584463375107cf@www.novabbs.org>, > MitchAlsup1 <mitchalsup@aol.com> wrote: >> On Thu, 20 Mar 2025 12:44:08 +0000, Dan Cross wrote: > >>> Sometimes you really don't want to be interrupted. >> And sometimes you don't want to be interrupted unless the >> "house is on fire"; I cannot see a time when "the house is >> on fire" that you would not want to take the interrupt. >> >> Is there one ?!? > > Consider a thread that takes a spinlock; suppose some > high-priority interrupt comes in while the thread is holding > that lock. In response to the interrupt, software decides to > suspend the thread and switch some other thread; that thread > wants to lock the spin lock that the now-descheduled thread is > holding: a classic deadlock scenario. Terminology: mutexes coordinate mutual exclusion between threads, spinlocks coordinate mutual exclusion between cpu cores. Windows "critical sections" are mutexes with a fast path. > A valid response here might be, "don't context switch from the > interrupt handler; use a DPC instead". That may be valid, but > it puts a constraint on the software designer that may be onerus > in practice: suppose the interrupt happens in the scheduler, > while examining a run queue or something. A DPC object must be > available, etc. That is exactly what DPC/SoftIrq are design to do - allow the bulk of the kernel, like the scheduler, non-paged heap management, IO pre and post processing, to be interrupted without causing reentrancy. The higher level device interrupt enqueues a request to the lower software interrupt level, which is processed when it will not cause reentrancy. That constraint is by design and any good OS will crash if violated. > Further, software must now consider the complexity of > potentially interruptable critical sections. From the > standpoint of reasoning about already-complex concurrency issues > it's simpler to be able to assert that (almost) all interrupt > delivery can be cheaply disabled entirely, save for very > special, specific, scenarios like NMIs. Potentially switching > away from a thread holding a spinlock sort of defeats the > purpose of a spinlock in the first place, which is a mutex > primitive designed to avoid the overhead of switching. > > - Dan C. This is why I mentioned the terminology thing: threads do not hold spinlocks, they hold mutexes. Threads and mutexes are a fiction created by the OS scheduler, and switching threads while waiting for a mutex is exactly what they are supposed to do. Spinlocks are used by cores to coordinate access to shared memory by things like a OS scheduler looking at list of threads waiting for a mutex. I like to think of it as all having to do with hats. The cpu is wearing one of three hats: a thread hat when it pretends to be a time shared execution machine; a core hat when it acts as a single execution machine running non-reentrant things like a scheduler which creates the fiction of threads and processes (multiple virtual spaces); and an interrupt hat when executing nestable reentrant interrupts. The interrupt mechanism coordinates exactly when and how we switch hats.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-24 12:09 -0700 |
| Message-ID | <vrsakc$1faj3$8@dont-email.me> |
| In reply to | #111266 |
On 3/24/2025 10:46 AM, EricP wrote: > Dan Cross wrote: >> In article <fe9715fa347144df1e584463375107cf@www.novabbs.org>, >> MitchAlsup1 <mitchalsup@aol.com> wrote: >>> On Thu, 20 Mar 2025 12:44:08 +0000, Dan Cross wrote: >> >>>> Sometimes you really don't want to be interrupted. >>> And sometimes you don't want to be interrupted unless the >>> "house is on fire"; I cannot see a time when "the house is >>> on fire" that you would not want to take the interrupt. >>> >>> Is there one ?!? >> >> Consider a thread that takes a spinlock; suppose some >> high-priority interrupt comes in while the thread is holding >> that lock. In response to the interrupt, software decides to >> suspend the thread and switch some other thread; that thread >> wants to lock the spin lock that the now-descheduled thread is >> holding: a classic deadlock scenario. > > Terminology: mutexes coordinate mutual exclusion between threads, > spinlocks coordinate mutual exclusion between cpu cores. > Windows "critical sections" are mutexes with a fast path. [...] Fwiw, they also have a "spin count", which might spin a couple of times on contention before they wait in the kernel. Trying to spin to gain a fast path before waiting in the kernel, wrt userspace logic. PAUSE instruction comes to mind. Iirc, they are called adaptive mutexes.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-24 20:11 +0000 |
| Message-ID | <vrsea2$siu$1@reader1.panix.com> |
| In reply to | #111266 |
In article <kVgEP.1277108$_N6e.605199@fx17.iad>, EricP <ThatWouldBeTelling@thevillage.com> wrote: >Dan Cross wrote: >> In article <fe9715fa347144df1e584463375107cf@www.novabbs.org>, >> MitchAlsup1 <mitchalsup@aol.com> wrote: >>> On Thu, 20 Mar 2025 12:44:08 +0000, Dan Cross wrote: >> >>>> Sometimes you really don't want to be interrupted. >>> And sometimes you don't want to be interrupted unless the >>> "house is on fire"; I cannot see a time when "the house is >>> on fire" that you would not want to take the interrupt. >>> >>> Is there one ?!? >> >> Consider a thread that takes a spinlock; suppose some >> high-priority interrupt comes in while the thread is holding >> that lock. In response to the interrupt, software decides to >> suspend the thread and switch some other thread; that thread >> wants to lock the spin lock that the now-descheduled thread is >> holding: a classic deadlock scenario. > >Terminology: mutexes coordinate mutual exclusion between threads, >spinlocks coordinate mutual exclusion between cpu cores. >Windows "critical sections" are mutexes with a fast path. A spin lock is simply any lock where you spin trying to acquire the lock, as opposed to a blocking synchronization protocol. Here I'm using the terminology of Herlihy and Shavit [Her08]. Traditional Unix "sleep" and "wakeup" are an example of a blocking protocol, where a thread may "sleep" on some "channel", yielding the locking thread while the lock cannot be acquired, presumably scheduling something else until the thread is later marked runnable by virtual of something else calling "wakeup" on the sleep channel. But note that I am deliberately simplifying in order to construct a particular scenario in which a light-weight synchronization primitive is being used for mutual exclusion between concurrent entities, hence mentioning spinlocks specifically. Suggesting that spin locks iare only applicable to multiprocessing scenarios is flatly incorrect. Software may use the technique to spin on a "busy" bit on some IP in a device for example, even on a uniprocessor system. >> A valid response here might be, "don't context switch from the >> interrupt handler; use a DPC instead". That may be valid, but >> it puts a constraint on the software designer that may be onerus >> in practice: suppose the interrupt happens in the scheduler, >> while examining a run queue or something. A DPC object must be >> available, etc. > >That is exactly what DPC/SoftIrq are design to do - allow the bulk of >the kernel, like the scheduler, non-paged heap management, IO pre and >post processing, to be interrupted without causing reentrancy. >The higher level device interrupt enqueues a request to the lower software >interrupt level, which is processed when it will not cause reentrancy. > >That constraint is by design and any good OS will crash if violated. Yes, I'm aware of the technique. That wasn't the point. >> Further, software must now consider the complexity of >> potentially interruptable critical sections. From the >> standpoint of reasoning about already-complex concurrency issues >> it's simpler to be able to assert that (almost) all interrupt >> delivery can be cheaply disabled entirely, save for very >> special, specific, scenarios like NMIs. Potentially switching >> away from a thread holding a spinlock sort of defeats the >> purpose of a spinlock in the first place, which is a mutex >> primitive designed to avoid the overhead of switching. > >This is why I mentioned the terminology thing: threads do not hold >spinlocks, they hold mutexes. See above. Threads can certainly "hold" a spin lock, as they can hold any kind of lock. To quote from sec 7.6.1 of [Val96], page 202: |On a uniprocessor, if a thread tries to acquire a spin lock |that is already held, it will loop forever. Multiprocessor |algorithms, however, must operate correctly regardless of the |number of processors, which means that they should handle the |uniprocessor case as well. This requires strict adherence to |the rule that threads not relinquish control of the CPU while |holding a spin lock. >Threads and mutexes are a fiction created >by the OS scheduler, and switching threads while waiting for a mutex >is exactly what they are supposed to do. > >Spinlocks are used by cores to coordinate access to shared memory by >things like a OS scheduler looking at list of threads waiting for a mutex. Spinlocks, of the form I was describing, are an optimization for cases where the critical section guarded by the lock is short, and the overhead of invoking a scheduler and context switching to some other thread is higher than just spinning until the lock becomes available again. The whole point is to avoid blocking and switching. E.g., as [Vaj11] puts it (page 98): |Spin locks have the advantage of preventing pre-emption by the |OS (due to blocking while waiting for the lock) That is, the advantage is because the thread does not block and yield. >I like to think of it as all having to do with hats. >The cpu is wearing one of three hats: a thread hat when it pretends to be >a time shared execution machine; a core hat when it acts as a single >execution machine running non-reentrant things like a scheduler which >creates the fiction of threads and processes (multiple virtual spaces); >and an interrupt hat when executing nestable reentrant interrupts. > >The interrupt mechanism coordinates exactly when and how we switch hats. I suppose you are lumping system calls into the overall bucket of "interrupts" in this model, regardless of whether one might use a dedicated supervisor call instruction (e.g., something like x86 SYSENTER or SYSCALL or ARM SVC or RISC-V's ECALL)? The hat analogy feels strained to me, and too colloquial to be useful. - Dan C. References: [Her08] Maurice Herlihy and Nir Shavit. 2008. _The Art of Multiprocessor Programming_. Morgan Kaufmann, Burlington, MA. [Vah96] Uresh Vahalia. 1996. _Unix Internals: The New Frontiers_. Prentice Hall, Upper Saddle River, NJ. [Vaj11] Andras Vajda. 2011. _Programming Many-Core Chips_. Springer, New York, NY.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-24 22:50 +0000 |
| Message-ID | <a86295425dfb043a1b44e550a1c05659@www.novabbs.org> |
| In reply to | #111277 |
On Mon, 24 Mar 2025 20:11:46 +0000, Dan Cross wrote:
> In article <kVgEP.1277108$_N6e.605199@fx17.iad>,
> EricP <ThatWouldBeTelling@thevillage.com> wrote:
>>Dan Cross wrote:
>>> In article <fe9715fa347144df1e584463375107cf@www.novabbs.org>,
>>> MitchAlsup1 <mitchalsup@aol.com> wrote:
-------------------
>>This is why I mentioned the terminology thing: threads do not hold
>>spinlocks, they hold mutexes.
>
> See above. Threads can certainly "hold" a spin lock, as they
> can hold any kind of lock. To quote from sec 7.6.1 of [Val96],
> page 202:
>
> |On a uniprocessor, if a thread tries to acquire a spin lock
> |that is already held, it will loop forever. Multiprocessor
> |algorithms, however, must operate correctly regardless of the
> |number of processors, which means that they should handle the
> |uniprocessor case as well. This requires strict adherence to
> |the rule that threads not relinquish control of the CPU while
> |holding a spin lock.
My 66000 ATOMIC stuff is designed such that if control has to leave
the ATOMIC event, all HW knowledge of being in that event disappears
and IP is modified (prior to control transfer) such that upon return
SW knows the event failed (or never started), and that no update of
participating data in the event ever becomes visible.
HW can do this with address-based events, but not with data-based
events. LDL-STC are address-based events used to manipulate data-
based events. Mine just allow more LDs and STs in the event than 1.
So, if you want the property whereby the lock disappears on any
control transfer out of the event {exception, interrupt, SVC, SVR, ...};
then you want to use my ATOMIC stuff; otherwise, you can use the
normal ATOMIC primitives everyone and his brother provide.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-24 23:45 +0000 |
| Message-ID | <vrsqrd$ns1$1@reader1.panix.com> |
| In reply to | #111281 |
In article <a86295425dfb043a1b44e550a1c05659@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>On Mon, 24 Mar 2025 20:11:46 +0000, Dan Cross wrote:
>
>> In article <kVgEP.1277108$_N6e.605199@fx17.iad>,
>> EricP <ThatWouldBeTelling@thevillage.com> wrote:
>>>Dan Cross wrote:
>>>> In article <fe9715fa347144df1e584463375107cf@www.novabbs.org>,
>>>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>-------------------
>>>This is why I mentioned the terminology thing: threads do not hold
>>>spinlocks, they hold mutexes.
>>
>> See above. Threads can certainly "hold" a spin lock, as they
>> can hold any kind of lock. To quote from sec 7.6.1 of [Val96],
>> page 202:
>>
>> |On a uniprocessor, if a thread tries to acquire a spin lock
>> |that is already held, it will loop forever. Multiprocessor
>> |algorithms, however, must operate correctly regardless of the
>> |number of processors, which means that they should handle the
>> |uniprocessor case as well. This requires strict adherence to
>> |the rule that threads not relinquish control of the CPU while
>> |holding a spin lock.
>
>My 66000 ATOMIC stuff is designed such that if control has to leave
>the ATOMIC event, all HW knowledge of being in that event disappears
>and IP is modified (prior to control transfer) such that upon return
>SW knows the event failed (or never started), and that no update of
>participating data in the event ever becomes visible.
>
>HW can do this with address-based events, but not with data-based
>events. LDL-STC are address-based events used to manipulate data-
>based events. Mine just allow more LDs and STs in the event than 1.
>
>So, if you want the property whereby the lock disappears on any
>control transfer out of the event {exception, interrupt, SVC, SVR, ...};
>then you want to use my ATOMIC stuff; otherwise, you can use the
>normal ATOMIC primitives everyone and his brother provide.
I definitely do Not want that property. Having a lock
"disappear" on delivery of an interrupt seems like it would be a
great way to introduce silent corruption.
If your atomic primitives are not sufficient to cover an entire
critical section, as I believe we have established, and are
mostly intended to be used for building concurrency primitives
like locks, then I expect that software would take the lock, see
that it succeeded, and enter the critical section. If at that
point the lock were silently discarded on receipt of an
interrupt, then potentially some other thread could subsequently
take the lock, enter the critical section, and observe a data
structure in an inconsistent state (leading to a crash in the
best case). This is precisely the sort of thing we build mutual
exclusion primitives to wrap around critical sections to avoid.
If, on the other hand, the atomic primitives are just meant for
the spin loop, then I don't really see how that's all that
useful compared to LL/SC. And you still need some way to ensure
that the critical section is not interrupted.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-25 01:53 +0000 |
| Message-ID | <e0080df32c6f88ebbd4c8828f98f76a9@www.novabbs.org> |
| In reply to | #111283 |
On Mon, 24 Mar 2025 23:45:49 +0000, Dan Cross wrote:
> In article <a86295425dfb043a1b44e550a1c05659@www.novabbs.org>,
> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>On Mon, 24 Mar 2025 20:11:46 +0000, Dan Cross wrote:
>>
>>> In article <kVgEP.1277108$_N6e.605199@fx17.iad>,
>>> EricP <ThatWouldBeTelling@thevillage.com> wrote:
>>>>Dan Cross wrote:
>>>>> In article <fe9715fa347144df1e584463375107cf@www.novabbs.org>,
>>>>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>-------------------
>>>>This is why I mentioned the terminology thing: threads do not hold
>>>>spinlocks, they hold mutexes.
>>>
>>> See above. Threads can certainly "hold" a spin lock, as they
>>> can hold any kind of lock. To quote from sec 7.6.1 of [Val96],
>>> page 202:
>>>
>>> |On a uniprocessor, if a thread tries to acquire a spin lock
>>> |that is already held, it will loop forever. Multiprocessor
>>> |algorithms, however, must operate correctly regardless of the
>>> |number of processors, which means that they should handle the
>>> |uniprocessor case as well. This requires strict adherence to
>>> |the rule that threads not relinquish control of the CPU while
>>> |holding a spin lock.
>>
>>My 66000 ATOMIC stuff is designed such that if control has to leave
>>the ATOMIC event, all HW knowledge of being in that event disappears
>>and IP is modified (prior to control transfer) such that upon return
>>SW knows the event failed (or never started), and that no update of
>>participating data in the event ever becomes visible.
>>
>>HW can do this with address-based events, but not with data-based
>>events. LDL-STC are address-based events used to manipulate data-
>>based events. Mine just allow more LDs and STs in the event than 1.
>>
>>So, if you want the property whereby the lock disappears on any
>>control transfer out of the event {exception, interrupt, SVC, SVR, ...};
>>then you want to use my ATOMIC stuff; otherwise, you can use the
>>normal ATOMIC primitives everyone and his brother provide.
>
> I definitely do Not want that property. Having a lock
> "disappear" on delivery of an interrupt seems like it would be a
> great way to introduce silent corruption.
It means that if a thread owning a lock is interrupted, that
thread gives the lock back--so there is no priority inversion
and no lock-starvation. Associated with the give back, and the
IP of the interrupted thread no longer points inside the
critical section.
Nothing gets lost.
{{Perhaps disappear was a poorly chosen word.}}
> If your atomic primitives are not sufficient to cover an entire
> critical section, as I believe we have established, and are
> mostly intended to be used for building concurrency primitives
> like locks, then I expect that software would take the lock, see
> that it succeeded, and enter the critical section.
>
> If at that
> point the lock were silently discarded on receipt of an
> interrupt,
At this point your thread in not IN the critical section !!
The closest you can be is at the first instruction beginning
an ATOMIC event (the never happened case) or you can also
be at the point where you KNOW that some other interfered
with your actions, and that they saw a completely consistent
state--now it is your turn (again) observing a completely
consistent but new state.
> then potentially some other thread could subsequently
> take the lock,
Since you are not in the critical section, you don't care.
No critical data has been modified, there is no inconsistent
state to be observed; and YOUR Instruction Pointer is not
pointing into instructions within the ATOMIC event !!
> enter the critical section, and observe a data
> structure in an inconsistent state (leading to a crash in the
> best case).
There is no inconsistent state--in rather the same way a core backs
up a branch mispredict, the core backs up the ATOMIC event to appear
as if it never even started !!
> This is precisely the sort of thing we build mutual
> exclusion primitives to wrap around critical sections to avoid.
And also why those primitives give rise to priority inversion
and lock-starvation.
> If, on the other hand, the atomic primitives are just meant for
> the spin loop, then I don't really see how that's all that
> useful compared to LL/SC.
Any number of respected people have ask for a pipelined LL-SC;
where one can LL multiple datums and later SC multiple datums.
This is what ESM can provide.
> And you still need some way to ensure
> that the critical section is not interrupted.
Just a way to detect if it happened; and if it happens;
means to back upto a point where it does not matter if
interference happened "right there"--that is: outside of
a critical section.
> - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-25 01:26 -0400 |
| Message-ID | <jwvmsd91yxy.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111284 |
> It means that if a thread owning a lock is interrupted, that
> thread gives the lock back--so there is no priority inversion
> and no lock-starvation. Associated with the give back, and the
> IP of the interrupted thread no longer points inside the
> critical section.
I think the discussion is a bit confusing because we have 2 different
notions of "critical section" at play, here:
Mitch's ESM/ATOMIC provides a kind of middle-point between LL/SC and
transactional memory, which handles only "very small" atomic sequences
(IIUC there's no limit to the number of instructions, but there's
a limit of 8 data cache lines touched).
A "critical section" can refer to such an atomic sequence. But that can
be used only for critical sections of limited size, so as you point out
it can't really be composed. For this reason, as Mitch said, it's meant
mostly as a tool to implement synchronization primitives (lock,
semaphore, read/write lock, younameit), tho it seems sufficiently
flexible that it should also be usable for some lock-free operations.
A "critical section" can also refer to the arbitrary code protected by
a lock, where the lock primitives would be presumably themselves
implemented using ESM and would then each be made of their own "critical
section".
The small ATOMIC-style critical sections don't hold locks. Instead they
use an optimistic-synchronization approach, which is why they don't
suffer from priority inversion.
The lock-based critical sections you can build on top of the ATOMIC-style
critical sections, OTOH, are just your usual lock-based critical
sections: the fact that they're built out of ESM primitives rather than
out of test&set or LL/SC doesn't really make any difference: they can
indeed suffer from priority inversion.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-25 00:07 -0700 |
| Message-ID | <vrtkmt$2paav$1@dont-email.me> |
| In reply to | #111288 |
On 3/24/2025 10:26 PM, Stefan Monnier wrote: >> It means that if a thread owning a lock is interrupted, that >> thread gives the lock back--so there is no priority inversion >> and no lock-starvation. Associated with the give back, and the >> IP of the interrupted thread no longer points inside the >> critical section. > > I think the discussion is a bit confusing because we have 2 different > notions of "critical section" at play, here: Yup. User space mutex impls vs kernel space ones (sync algos, mutexes, ect...), that can be different in the way they are implemented. Using an XCHG instruction can give you a spinlock, mutex, ect... CMPXCHG and XCHG are very fun, never forget about XADD. In user space we only want to resort to the kernel to wait when we have to... We try to minimize that as the slow path, the last resort. The fast path can get around calling into the kernel. Spinning in user space on a contended mutex is okay as long as its rather limited. Then it can be called an adaptive mutex. [...]
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 12:23 +0000 |
| Message-ID | <vru785$614$1@reader1.panix.com> |
| In reply to | #111284 |
In article <e0080df32c6f88ebbd4c8828f98f76a9@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>On Mon, 24 Mar 2025 23:45:49 +0000, Dan Cross wrote:
>> In article <a86295425dfb043a1b44e550a1c05659@www.novabbs.org>,
>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>>[snip]
>>>My 66000 ATOMIC stuff is designed such that if control has to leave
>>>the ATOMIC event, all HW knowledge of being in that event disappears
>>>and IP is modified (prior to control transfer) such that upon return
>>>SW knows the event failed (or never started), and that no update of
>>>participating data in the event ever becomes visible.
>>>
>>>HW can do this with address-based events, but not with data-based
>>>events. LDL-STC are address-based events used to manipulate data-
>>>based events. Mine just allow more LDs and STs in the event than 1.
>>>
>>>So, if you want the property whereby the lock disappears on any
>>>control transfer out of the event {exception, interrupt, SVC, SVR, ...};
>>>then you want to use my ATOMIC stuff; otherwise, you can use the
>>>normal ATOMIC primitives everyone and his brother provide.
>>
>> I definitely do Not want that property. Having a lock
>> "disappear" on delivery of an interrupt seems like it would be a
>> great way to introduce silent corruption.
>
>It means that if a thread owning a lock is interrupted, that
>thread gives the lock back--so there is no priority inversion
>and no lock-starvation. Associated with the give back, and the
>IP of the interrupted thread no longer points inside the
>critical section.
>
>Nothing gets lost.
Perhaps we're not clear on what a "lock" is. Here, I'm
referring to a mutual exclusion primitive that I use to protect
entry into a critical section. You seem to be talking about
something else.
>{{Perhaps disappear was a poorly chosen word.}}
>
>> If your atomic primitives are not sufficient to cover an entire
>> critical section, as I believe we have established, and are
>> mostly intended to be used for building concurrency primitives
>> like locks, then I expect that software would take the lock, see
>> that it succeeded, and enter the critical section.
>>
>> If at that
>> point the lock were silently discarded on receipt of an
>> interrupt,
>
>At this point your thread in not IN the critical section !!
Why not? I successfully acquired a lock, no? What else do you
propose I must do to enter the critical section?
>The closest you can be is at the first instruction beginning
>an ATOMIC event (the never happened case) or you can also
>be at the point where you KNOW that some other interfered
>with your actions, and that they saw a completely consistent
>state--now it is your turn (again) observing a completely
>consistent but new state.
Here's a bit of my earlier message that didn't get quoted in
your reply:
|If, on the other hand, the atomic primitives are just meant for
|the spin loop, then I don't really see how that's all that
|useful compared to LL/SC. And you still need some way to ensure
|that the critical section is not interrupted.
It seems like you're saying that the "ATOMIC event" is just for
the spin loop.
>> then potentially some other thread could subsequently
>> take the lock,
>
>Since you are not in the critical section, you don't care.
>No critical data has been modified, there is no inconsistent
>state to be observed; and YOUR Instruction Pointer is not
>pointing into instructions within the ATOMIC event !!
This seems to be predicated on something that you understand
about this mechanism that you've proposed, but haven't quite
explained (or perhaps that I haven't understood).
So again, I ask my question, how do I get into the critical
section? Given the text quoted above from my last reply, what
is the utility of these atomic events vis that goal?
It sounds like you're saying that I can use them to implement a
traditional spin lock. But then how are they better than a
"normal" atomic CAS? You mention respecting priority and in
particular avoiding inversion, but I don't think that's actually
true: consider some critical section, where I cannot yield the
CPU to another thread, even one running at higher priority,
since I'm manipulating some data structure and it is important
that that data structure not be in an intermediate state when
I get switched away from; this strongly implies that I use these
atomic primitives to build the sort of lock where I set some
_other_ datum, not the "lock" manipulated in the atomic event,
to indicate that I'm in the critical section: but if that's the
case, then what prevents some other, higher priority thread,
from attempting to enter the critical section _when I'm in it_,
but not when I'm racing on the lock?
E.g., this sequence of events:
Thread A (lo pri) Thread B (hi pri)
-------- --------
Atomic lock
Observe success
Acquire mutex
Unlock
Atomic Lock
Observe success
Observe that mutex is already set
Unlock
Now what?
>> enter the critical section, and observe a data
>> structure in an inconsistent state (leading to a crash in the
>> best case).
>
>There is no inconsistent state--in rather the same way a core backs
>up a branch mispredict, the core backs up the ATOMIC event to appear
>as if it never even started !!
We've already established that this cannot cover all use cases.
See my example of popping off of a queue and inserting into an
ordered list.
>> This is precisely the sort of thing we build mutual
>> exclusion primitives to wrap around critical sections to avoid.
>
>And also why those primitives give rise to priority inversion
>and lock-starvation.
But this mechanism is insufficient to actually address those
problems in anything but the most limited ways. See the example
above.
Moreover, those are problems that are well understood and are
successfully mitigated in real world systems. I do not see any
evidence that they are sufficiently problematic supporting the
introduction of a brand new mechanism with poorly understood
behavior and what seems like very complex semantics.
>> If, on the other hand, the atomic primitives are just meant for
>> the spin loop, then I don't really see how that's all that
>> useful compared to LL/SC.
>
>Any number of respected people have ask for a pipelined LL-SC;
>where one can LL multiple datums and later SC multiple datums.
>This is what ESM can provide.
Who are these folks and have any of them chimed in on this
proposal? It seems like you've gone far beyond "pipelined
LL-SC" and introduced notions of threads and priorities that
interact with that in complex and, frankly, undesirable ways.
>> And you still need some way to ensure
>> that the critical section is not interrupted.
>
>Just a way to detect if it happened; and if it happens;
>means to back upto a point where it does not matter if
>interference happened "right there"--that is: outside of
>a critical section.
This is based on the fallacious assumption that that is possible
in the general case. I think I have shown that it is not.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-25 13:45 +0000 |
| Message-ID | <7syEP.1258092$FVcd.41667@fx10.iad> |
| In reply to | #111284 |
mitchalsup@aol.com (MitchAlsup1) writes:
>On Mon, 24 Mar 2025 23:45:49 +0000, Dan Cross wrote:
>>>So, if you want the property whereby the lock disappears on any
>>>control transfer out of the event {exception, interrupt, SVC, SVR, ...};
>>>then you want to use my ATOMIC stuff; otherwise, you can use the
>>>normal ATOMIC primitives everyone and his brother provide.
>>
>> I definitely do Not want that property. Having a lock
>> "disappear" on delivery of an interrupt seems like it would be a
>> great way to introduce silent corruption.
>
>It means that if a thread owning a lock is interrupted, that
>thread gives the lock back--so there is no priority inversion
>and no lock-starvation. Associated with the give back, and the
>IP of the interrupted thread no longer points inside the
>critical section.
>
>Nothing gets lost.
This isn't a hardware transaction. If the thread has updated data
and you take away the lock, the system is now inconsistent
and nasal daemons will ensue.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-25 15:01 +0000 |
| Message-ID | <b201b9212700f9359a831e03b1d60cef@www.novabbs.org> |
| In reply to | #111296 |
On Tue, 25 Mar 2025 13:45:39 +0000, Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >>Nothing gets lost. > > This isn't a hardware transaction. If the thread has updated data > and you take away the lock, the system is now inconsistent > and nasal daemons will ensue. In HW there is a little thing known as branch misprediction repair, where all the work done is made to appear as if those instructions were never executed to begin with. The size of the branch mispredict window is on the order of 300 instructions now. With Spectré and Meltdown even cache updates must be delayed until after the causing instruction retires.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 15:10 +0000 |
| Message-ID | <vruh0r$lqf$2@reader1.panix.com> |
| In reply to | #111298 |
In article <b201b9212700f9359a831e03b1d60cef@www.novabbs.org>, MitchAlsup1 <mitchalsup@aol.com> wrote: >On Tue, 25 Mar 2025 13:45:39 +0000, Scott Lurndal wrote: > >> mitchalsup@aol.com (MitchAlsup1) writes: > >>>Nothing gets lost. >> >> This isn't a hardware transaction. If the thread has updated data >> and you take away the lock, the system is now inconsistent >> and nasal daemons will ensue. > >In HW there is a little thing known as branch misprediction repair, >where all the work done is made to appear as if those instructions >were never executed to begin with. The size of the branch mispredict >window is on the order of 300 instructions now. > >With Spectré and Meltdown even cache updates must be delayed until >after the causing instruction retires. But again, that's irrelevant. The "critical sections" in question here are software abstractions created by system software. What you're describing is at the microarchitectural level; two totally different worlds. I think the fundamental mismatch here is that you're trying to apply this solution you have created for something at the uarch level to a problem at the systems software level. It's jut not a good fit. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-25 16:40 +0000 |
| Message-ID | <0343529d63f68c76b5e0d227ef6e39dd@www.novabbs.org> |
| In reply to | #111300 |
On Tue, 25 Mar 2025 15:10:19 +0000, Dan Cross wrote:
> In article <b201b9212700f9359a831e03b1d60cef@www.novabbs.org>,
> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>On Tue, 25 Mar 2025 13:45:39 +0000, Scott Lurndal wrote:
>>
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>
>>>>Nothing gets lost.
>>>
>>> This isn't a hardware transaction. If the thread has updated data
>>> and you take away the lock, the system is now inconsistent
>>> and nasal daemons will ensue.
>>
>>In HW there is a little thing known as branch misprediction repair,
>>where all the work done is made to appear as if those instructions
>>were never executed to begin with. The size of the branch mispredict
>>window is on the order of 300 instructions now.
>>
>>With Spectré and Meltdown even cache updates must be delayed until
>>after the causing instruction retires.
>
> But again, that's irrelevant. The "critical sections" in
> question here are software abstractions created by system
> software.
Say you have a critical section (of your description) that was
preceded by an if-statement that was predicted to enter CS, but
1,000 cycles later the branch is resolved to not enter the CS.
{{Branch was dependent on an MMI/O location down the PCIe tree
which is why it took so long to resolve.}}
HW Backs the core up so that the RF and all memory locations
contain their original values at the point of the mispredicted
branch.
Can thread running on core even tell if you entered CS or not !
No, your thread cannot.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 17:54 +0000 |
| Message-ID | <vruql2$cv2$3@reader1.panix.com> |
| In reply to | #111304 |
In article <0343529d63f68c76b5e0d227ef6e39dd@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>On Tue, 25 Mar 2025 15:10:19 +0000, Dan Cross wrote:
>> In article <b201b9212700f9359a831e03b1d60cef@www.novabbs.org>,
>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>>On Tue, 25 Mar 2025 13:45:39 +0000, Scott Lurndal wrote:
>>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>>Nothing gets lost.
>>>>
>>>> This isn't a hardware transaction. If the thread has updated data
>>>> and you take away the lock, the system is now inconsistent
>>>> and nasal daemons will ensue.
>>>
>>>In HW there is a little thing known as branch misprediction repair,
>>>where all the work done is made to appear as if those instructions
>>>were never executed to begin with. The size of the branch mispredict
>>>window is on the order of 300 instructions now.
>>>
>>>With Spectré and Meltdown even cache updates must be delayed until
>>>after the causing instruction retires.
>>
>> But again, that's irrelevant. The "critical sections" in
>> question here are software abstractions created by system
>> software.
>
>Say you have a critical section (of your description) that was
>preceded by an if-statement that was predicted to enter CS, but
>1,000 cycles later the branch is resolved to not enter the CS.
>{{Branch was dependent on an MMI/O location down the PCIe tree
>which is why it took so long to resolve.}}
>
>HW Backs the core up so that the RF and all memory locations
>contain their original values at the point of the mispredicted
>branch.
>
>Can thread running on core even tell if you entered CS or not !
>
>No, your thread cannot.
Again, how is that relevant? The branch predictor can only
handle speculative execution of so-many instructions. Attempts
to perform more instructions than that will stall the pipeline.
A critical section as defined by software may contain more than
that number of instructions. A critical section, as defined by
software, may touch more cache lines than your atomic event
proposal can handle. Thus, for your architecture to be useful,
you must provide some mechanism for handling those
eventualities.
Your stuff sounds fine for getting into the critsec; but it
doesn't help you once you're in it, and it seems like it may
hurt you if some higher-priority thing comes along and yanks
your lock out from under you.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-25 20:40 +0000 |
| Message-ID | <e4ecfb53ef4f33f10b6d2548d5930159@www.novabbs.org> |
| In reply to | #111309 |
On Tue, 25 Mar 2025 17:54:42 +0000, Dan Cross wrote:
> In article <0343529d63f68c76b5e0d227ef6e39dd@www.novabbs.org>,
> MitchAlsup1 <mitchalsup@aol.com> wrote:
--------------------------
>>
>>Say you have a critical section (of your description) that was
>>preceded by an if-statement that was predicted to enter CS, but
>>1,000 cycles later the branch is resolved to not enter the CS.
>>{{Branch was dependent on an MMI/O location down the PCIe tree
>>which is why it took so long to resolve.}}
>>
>>HW Backs the core up so that the RF and all memory locations
>>contain their original values at the point of the mispredicted
>>branch.
>>
>>Can thread running on core even tell if you entered CS or not !
>>
>>No, your thread cannot.
>
> Again, how is that relevant? The branch predictor can only
> handle speculative execution of so-many instructions.
Around 300 at present.
Know of any critical sections that long?
> Attempts
> to perform more instructions than that will stall the pipeline.
Obviously.
> A critical section as defined by software may contain more than
> that number of instructions.
Sure, its possible.
But if DECODE cannot push the entire critical section into the
execution window, then BY DEFINITION, it MUST be able to make
the entire critical section appear as if you never started on
it !!!
IP gets backed up as if you never entered CS
RF gets backed up as if you never entered CS
LOCK variable never got written to SNOOPable cache where others can see
it
Cache memory gets put back in the "you never got here" states too.
Thus, it is like it never happened:: both to the core and to all
interested 3rd parties.
Nobody saw the Lock variable change value.
And
Nobody saw any STs from the CS change anything in memory.
Thus, it is as if CS never happened, it was all speculative, and
got put-right when CS was not allowed to finish.
BUT-----------------------------
Code running in CS does believe the the LOCK variable was updated
AND that STs from CS have been performed by the exit of CS
------------------------------------------------------------
You see SW sees the nonNeumann model. 1 instruction is Fetched
and executed in its entirely before proceeding to the next inst-
ruction. You see individual instructions--as if single stepping.
HW, on the other hand sees at least 3 points in time
a) instructions has not arrived to be execcuted
b) instruction is executing
c) instruction has completed executing
And the time span from 1) to c) can be hundreds of cycles
while there are 300 (or more) instruction contending for
execution resources.
In additions, certain instructions may have more than 1 b) units
of timing--for example a LD-OP-ST has a LD execution, an OP
execution, and a ST execution.
But look at the execution of a ST in the shadow of a branch.
We want ST to be "performed" as soon as possible, so that a
subsequent LD can obtain the ST-data even before we are allowed
to write ST-data into the cache. So, your notion of what can be
backed up (or not) appears not to be able to see all the funny
business HW goes through to make the core smell fast.
After the LD receives ST-data, the branch may resolve as a
bad prediction, and the ST is not allowed to modify cache,
also the LD was not allowed to see data that was never to be
written. And HW clean up making it all SMELL like it never
happened.
-----------------------------------------------------------
Interested 3rd parties are another problem to be solved.
In the midst of a CS a SNOOP comes along and touches a memory
location you are using in CS.
a) You can make the CS appear never to have happened
b) you can delay the SNOOP response
c) You can wait for the branch to resolve to choose
...between a) and b)
d) same as c) but coherence protocol has a NaK in it.
(c) is only an option for more advance cache coherence protocols.
(d) allows a CS in the manifestation part (Sts) to have priority
(sic.) over interfering SNOOP requests--a soft guarantee of for-
ward progress.
> A critical section, as defined by
> software, may touch more cache lines than your atomic event
> proposal can handle.
Sure, but then you would only be using my ATOMICs for locking/
unlocking not for the work going on.
> Thus, for your architecture to be useful,
> you must provide some mechanism for handling those
> eventualities.
As stated about 15 responses ago, just use them as ATOMIC primitive
generators.
> Your stuff sounds fine for getting into the critsec; but it
> doesn't help you once you're in it, and it seems like it may
> hurt you if some higher-priority thing comes along and yanks
> your lock out from under you.
I conceded that point at least 2 days ago.
> - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 22:19 +0000 |
| Message-ID | <vrva4r$9ka$1@reader1.panix.com> |
| In reply to | #111313 |
In article <e4ecfb53ef4f33f10b6d2548d5930159@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>On Tue, 25 Mar 2025 17:54:42 +0000, Dan Cross wrote:
>
>> In article <0343529d63f68c76b5e0d227ef6e39dd@www.novabbs.org>,
>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>--------------------------
>>>
>>>Say you have a critical section (of your description) that was
>>>preceded by an if-statement that was predicted to enter CS, but
>>>1,000 cycles later the branch is resolved to not enter the CS.
>>>{{Branch was dependent on an MMI/O location down the PCIe tree
>>>which is why it took so long to resolve.}}
>>>
>>>HW Backs the core up so that the RF and all memory locations
>>>contain their original values at the point of the mispredicted
>>>branch.
>>>
>>>Can thread running on core even tell if you entered CS or not !
>>>
>>>No, your thread cannot.
>>
>> Again, how is that relevant? The branch predictor can only
>> handle speculative execution of so-many instructions.
>
>Around 300 at present.
>Know of any critical sections that long?
Oh, absolutely.
But that's besides the point. The point is that software _can_
exceed that limit, even if it's a bad idea to do so; it may not
even be immediately obvious to the programmer, who is most
likely working in a high-level langauge, not assembler.
How will your design accommodate that eventuality?
>> Attempts
>> to perform more instructions than that will stall the pipeline.
>
>Obviously.
>
>> A critical section as defined by software may contain more than
>> that number of instructions.
>
>Sure, its possible.
>
>But if DECODE cannot push the entire critical section into the
>execution window, then BY DEFINITION, it MUST be able to make
>the entire critical section appear as if you never started on
>it !!!
So ... what, you just don't execute it? Always skip over it?
Software needs to ensure serial access to some resource. That's
what critical sections are for. Your architecture needs to
support that.
From what I gather, you've said to just eschew the atomic event
stuff and build a traditional lock using those primitives. But
you have also said that a traditional lock can be silently
unlocked if the thread holding it (which, apparently, is an
abstraction known to hardware) is preempted. It will be like
the lock had never been acquired.
But here's the impedence mismatch: it appears that that happens
_after_ software has already made a decision based on something
that is rolled back later. If that's mistaken, then say so, but
if not, then the scheme is fatally flawed: there is literally no
way you can use it reliably to build anything that doesn't fit
into your atomic window.
>IP gets backed up as if you never entered CS
>RF gets backed up as if you never entered CS
>LOCK variable never got written to SNOOPable cache where others can see
>it
>Cache memory gets put back in the "you never got here" states too.
>
>[...a lot of the same stuff, repeated over and over snipped]
>
>> A critical section, as defined by
>> software, may touch more cache lines than your atomic event
>> proposal can handle.
>
>Sure, but then you would only be using my ATOMICs for locking/
>unlocking not for the work going on.
Indeed; that's what I've been saying.
But you also seem to imply that if a higher priority interrupt
comes along and preempts the code that's in the critical section
it will silently unlock the lock that is used to serialize entry
into the critical section. Is that correct? If so, do you see
how that makes the whole facility useless for building robust
mutual exclusion primitives? A lock that is silently released
because something else comes along and wants a turn instead is
no lock at all.
>> Thus, for your architecture to be useful,
>> you must provide some mechanism for handling those
>> eventualities.
>
>As stated about 15 responses ago, just use them as ATOMIC primitive
>generators.
Yes. Was that the same response where you said the lock would
be silently released if a higher-priority interrupt came along?
>> Your stuff sounds fine for getting into the critsec; but it
>> doesn't help you once you're in it, and it seems like it may
>> hurt you if some higher-priority thing comes along and yanks
>> your lock out from under you.
>
>I conceded that point at least 2 days ago.
Ok, now we're back to the question then: what purpose does it
serve? It doesn't seem like it can be usefully applied to
anything other than building traditional mutexes based on spin
locks, and even then I'm not sure if that's correct (see above).
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-03-25 18:49 -0400 |
| Message-ID | <jwvjz8coho7.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111314 |
Dan Cross [2025-03-25 22:19:07] wrote:
> From what I gather, you've said to just eschew the atomic event
> stuff and build a traditional lock using those primitives. But
> you have also said that a traditional lock can be silently
> unlocked if the thread holding it (which, apparently, is an
> abstraction known to hardware) is preempted. It will be like
> the lock had never been acquired.
Here's the misunderstanding: the lock that can be silently taken away
is the lock implemented in the CPU to run an ATOMIC sequence, not the
lock implemented as a data-structure on top of it: once you've run
(atomically) your `lock_acquire`, of course that lock is yours. The CPU
doesn't even know that this data-structure is a lock and has no
way to steal it.
Stefan
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web