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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-19 19:03 +0000 |
| Message-ID | <74e78c0000bed65badd46df507ea73c4@www.novabbs.org> |
| In reply to | #111232 |
On Wed, 19 Mar 2025 16:14:45 +0000, Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >>On Wed, 19 Mar 2025 13:49:54 +0000, Scott Lurndal wrote: >> >>> mitchalsup@aol.com (MitchAlsup1) writes: >>>>On Tue, 18 Mar 2025 21:59:51 +0000, Robert Finch wrote: >>>> >>>>> On 2025-03-18 2:51 p.m., EricP wrote: >>>>---------------- >>> >>>>> Seems like it could work. There are difficulties using counters with the >>>>> Q+ ISA as multiple interrupt enable bits could be manipulated at the >>>>> same time. One interrupt may be enabled and another one disabled by the >>>>> same instruction. >>>> >>>>I want to address the elephant in the room:: >>>> >>>>Why disable interrupts AT ALL !! >>> >>> Because sometimes you need to. For example, when making a configuration >>> change to the device, you'll want to disable interrupts that may be >>> generated as a result of the configuration change (e.g. when flushing >>> a FIFO on the device, you may not want the 'FIFO Empty' interrupt >>> to be asserted). >> >>The above is more quickly performed by raising the priority level above >>those of interrupts a device may send. > > Most device interrupts have the same priority. So your solution blocks > all interrupts effectively, Only to the core that took the interrupt, other cores remain to take those other exceptions--and only for the duration of the interrupt processing. So if you have 100 cores, and one is processing SATA[k] on core[j], there are 99 other cores that can take any pending interrupt from that or other interrupt tables. > even though only the interrupt for the particular > device owned by the device driver needs to be blocked.* Enabling really > needs to be done on a per-device-instance basis. Are you now arguing that interrupt en/disable should be processed at the device-instance ?? that is far from the core !! Certainly if the device-instance has not been assigned to a core/VM then it should not be sending interrupts (to anyone). This can be done at any of the first 4 layers of interrupt enablement. Heck--it is unlikely to have an interrupt table assigned, and would get terminated by the I/O MMU (if not before). But during the assignment to a core/VM the device has the routing (I/O MMU) to send interrupts that can be taken by a core running that GuestOS/VM. > There aren't enough priorities to have a separate priority for each > device instance (e.g. 1000 virtual functions owned by a single PF, > each with 10 individual interrupts). Priority only does the second order of the sort, allowing certain interrupts to bypass in front of other interrupts. Interrupt table selection/assignment does a first level of sort. Then who is looking at which table performs the third layer of the sort/routing. > If every device was required to have different priorities, you have > a nightmare scenario just trying to figure out which device interrupt > should be where in the priority hierarchy to avoid potential deadlocks. Multiple device-instances will use different interrupt tables as each GuestOS/VM has at least its own interrupt table. In which case, the priority in one table is orthogonal to the priority in another table. (*) comming back to:: > even though only the interrupt for the particular > device owned by the device driver needs to be blocked.* The interrupts are queued and until the priority of the core drops below that of the pending interrupts, the driver is not stimulated into activity again (recursively or reentrantly).
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-19 14:03 +0000 |
| Message-ID | <vreisc$dqb$1@reader1.panix.com> |
| In reply to | #111220 |
In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>, MitchAlsup1 <mitchalsup@aol.com> wrote: >I want to address the elephant in the room:: > >Why disable interrupts AT ALL !! So that you can have some mechanism for building critical sections that span multiple instructions, where just having access to atomics and spin locks isn't enough. >When running at any privilege, do you not want to accept an interrupt >at higher priority with as little delay as possible ?? Usually the assumption is that the critical section is short; a handful of instructions, perhaps, so that the cost of blocking a high priority interrupt is low. >Does Interrupt Disable help in this goal ?? This is predicated on an incomplete view of the situation and the intersection between hardware and software. Serving high priority interrupts quickly is not the only consideration. >Is there a SANE way to avoid disabling of interrupts ?? It depends on your definition of "sane" in this context. One may imagine redesigning all of a system's locking primitives, perhaps, to avoid the need to block interrupts in most cases. But that pushes a lot of complexity onto software for dubious benefit, and even then, it's not clear to me that they can be blocked in _all_ cases. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-19 15:59 +0000 |
| Message-ID | <af2d54a7c6c694bf18bcca6e6876a72b@www.novabbs.org> |
| In reply to | #111226 |
On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote: > In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>, > MitchAlsup1 <mitchalsup@aol.com> wrote: >>I want to address the elephant in the room:: >> >>Why disable interrupts AT ALL !! > > So that you can have some mechanism for building critical > sections that span multiple instructions, where just having > access to atomics and spin locks isn't enough. You can do this with priority, too. >>When running at any privilege, do you not want to accept an interrupt >>at higher priority with as little delay as possible ?? > > Usually the assumption is that the critical section is short; a > handful of instructions, perhaps, so that the cost of blocking a > high priority interrupt is low. > >>Does Interrupt Disable help in this goal ?? > > This is predicated on an incomplete view of the situation and > the intersection between hardware and software. Serving high > priority interrupts quickly is not the only consideration. > >>Is there a SANE way to avoid disabling of interrupts ?? > > It depends on your definition of "sane" in this context. One > may imagine redesigning all of a system's locking primitives, > perhaps, to avoid the need to block interrupts in most cases. > But that pushes a lot of complexity onto software for dubious > benefit, and even then, it's not clear to me that they can be > blocked in _all_ cases. > > - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-20 12:44 +0000 |
| Message-ID | <vrh2io$8vn$1@reader1.panix.com> |
| In reply to | #111230 |
In article <af2d54a7c6c694bf18bcca6e6876a72b@www.novabbs.org>, MitchAlsup1 <mitchalsup@aol.com> wrote: >On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote: > >> In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>, >> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>I want to address the elephant in the room:: >>> >>>Why disable interrupts AT ALL !! >> >> So that you can have some mechanism for building critical >> sections that span multiple instructions, where just having >> access to atomics and spin locks isn't enough. > >You can do this with priority, too. In the limit, disabling interrupts is just setting the priority mask to infinity, so in some sense this is de facto true. But I don't see how having a prioritization scheme is all that useful. Consider that when you're starting the system up, you need to do things like set up an interrupt handler vector, and so on; surely you want to block all interrupts until you have done so. If your system model is that receipt of an interrupt may result in a context switch, and you don't want to do that while holding a mutex similarly. Sometimes you really don't want to be interrupted. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-20 19:41 +0000 |
| Message-ID | <fe9715fa347144df1e584463375107cf@www.novabbs.org> |
| In reply to | #111239 |
On Thu, 20 Mar 2025 12:44:08 +0000, Dan Cross wrote: > In article <af2d54a7c6c694bf18bcca6e6876a72b@www.novabbs.org>, > MitchAlsup1 <mitchalsup@aol.com> wrote: >>On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote: >> >>> In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>, >>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>>I want to address the elephant in the room:: >>>> >>>>Why disable interrupts AT ALL !! >>> >>> So that you can have some mechanism for building critical >>> sections that span multiple instructions, where just having >>> access to atomics and spin locks isn't enough. >> >>You can do this with priority, too. > > In the limit, disabling interrupts is just setting the priority > mask to infinity, so in some sense this is de facto true. But I > don't see how having a prioritization scheme is all that useful. > Consider that when you're starting the system up, you need to > do things like set up an interrupt handler vector, and so on; The Interrupt vector is completely software. HW delivers the MSI-X message and the service for which this message is for, and SW decides what to do with this message to that service provider. No HW vectoring but HW does deliver all the bits needed to guide SW to its goal. > surely you want to block all interrupts until you have done so. I did not say I don't HAVE an interrupt disable, I state that one receives control in an already reentrant state, so the typical uses of ID are not in play--and I want to talk about the other uses of ID. You are doing a fine job. > If your system model is that receipt of an interrupt may result > in a context switch, and you don't want to do that while holding > a mutex similarly. Given the privilege to set priority, setting of priority is that same 1 cycle event that setting or clearing ID would be. > 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 ?!? > - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-20 20:25 +0000 |
| Message-ID | <vrhtkn$k7t$1@reader1.panix.com> |
| In reply to | #111242 |
In article <fe9715fa347144df1e584463375107cf@www.novabbs.org>, MitchAlsup1 <mitchalsup@aol.com> wrote: >On Thu, 20 Mar 2025 12:44:08 +0000, Dan Cross wrote: > >> In article <af2d54a7c6c694bf18bcca6e6876a72b@www.novabbs.org>, >> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote: >>> >>>> In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>, >>>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>>>I want to address the elephant in the room:: >>>>> >>>>>Why disable interrupts AT ALL !! >>>> >>>> So that you can have some mechanism for building critical >>>> sections that span multiple instructions, where just having >>>> access to atomics and spin locks isn't enough. >>> >>>You can do this with priority, too. >> >> In the limit, disabling interrupts is just setting the priority >> mask to infinity, so in some sense this is de facto true. But I >> don't see how having a prioritization scheme is all that useful. >> Consider that when you're starting the system up, you need to >> do things like set up an interrupt handler vector, and so on; > >The Interrupt vector is completely software. HW delivers the MSI-X >message and the service for which this message is for, and SW decides >what to do with this message to that service provider. No HW vectoring >but HW does deliver all the bits needed to guide SW to its goal. Maybe I'm missing the context here, and apologies if I am. But which interrupt disable are we talking about here, and where? I am coming at this from the perspective of systems software running on some CPU core somewhere; if I want that software to enter a critical section that cannot be interrupted, then it seems to me that MSI-X delivery is just a detail at that point. I might want to prevent IPIs, or delivery or local interrupts attached directly to the CPU (or something like an IOAPIC or GIC distributor). In any event, if software isn't prepared to receive an interrupt then there must necessarily be some mechanism to disable interrupt delivery until it is. >> surely you want to block all interrupts until you have done so. > >I did not say I don't HAVE an interrupt disable, I state that one >receives control in an already reentrant state, so the typical >uses of ID are not in play--and I want to talk about the other >uses of ID. You are doing a fine job. I suppose what I'm saying in part is that the "typical users" all depend on the system's software architecture. The ability to handle nested interrupts at the hardware level is all well and good, but doesn't matter if software can't handle it. >> If your system model is that receipt of an interrupt may result >> in a context switch, and you don't want to do that while holding >> a mutex similarly. > >Given the privilege to set priority, setting of priority is that >same 1 cycle event that setting or clearing ID would be. I guess I don't see how that is relevant. I mean, again, I suppose you could say, "set the priority mask to infinity to de facto disable interrupts", but that seems like a distinction without a difference. >> 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. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-20 21:55 +0000 |
| Message-ID | <4603ec2d5082f16ab0588b4b9d6f96c7@www.novabbs.org> |
| In reply to | #111244 |
On Thu, 20 Mar 2025 20:25:59 +0000, 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: >> >>> In article <af2d54a7c6c694bf18bcca6e6876a72b@www.novabbs.org>, >>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>>On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote: >>>> >>>>> In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>, >>>>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>>>>I want to address the elephant in the room:: >>>>>> >>>>>>Why disable interrupts AT ALL !! >>>>> >>>>> So that you can have some mechanism for building critical >>>>> sections that span multiple instructions, where just having >>>>> access to atomics and spin locks isn't enough. >>>> >>>>You can do this with priority, too. >>> >>> In the limit, disabling interrupts is just setting the priority >>> mask to infinity, so in some sense this is de facto true. But I >>> don't see how having a prioritization scheme is all that useful. >>> Consider that when you're starting the system up, you need to >>> do things like set up an interrupt handler vector, and so on; >> >>The Interrupt vector is completely software. HW delivers the MSI-X >>message and the service for which this message is for, and SW decides >>what to do with this message to that service provider. No HW vectoring >>but HW does deliver all the bits needed to guide SW to its goal. > > Maybe I'm missing the context here, and apologies if I am. But > which interrupt disable are we talking about here, and where? I We are talking about the core's Interrupt Disablement and nothing of the gates farther out in the system that control interrupt deliveries (or not). > am coming at this from the perspective of systems software > running on some CPU core somewhere; if I want that software to > enter a critical section that cannot be interrupted, then it > seems to me that MSI-X delivery is just a detail at that point. > I might want to prevent IPIs, or delivery or local interrupts > attached directly to the CPU (or something like an IOAPIC or > GIC distributor). All of those flow through the same mechanism; even a locally generated timer interrupt. > In any event, if software isn't prepared to receive an interrupt > then there must necessarily be some mechanism to disable > interrupt delivery until it is. I agree with this notion. >>> surely you want to block all interrupts until you have done so. >> >>I did not say I don't HAVE an interrupt disable, I state that one >>receives control in an already reentrant state, so the typical >>uses of ID are not in play--and I want to talk about the other >>uses of ID. You are doing a fine job. > > I suppose what I'm saying in part is that the "typical users" > all depend on the system's software architecture. The ability > to handle nested interrupts at the hardware level is all well > and good, but doesn't matter if software can't handle it. > >>> If your system model is that receipt of an interrupt may result >>> in a context switch, and you don't want to do that while holding >>> a mutex similarly. >> >>Given the privilege to set priority, setting of priority is that >>same 1 cycle event that setting or clearing ID would be. > > I guess I don't see how that is relevant. I mean, again, I > suppose you could say, "set the priority mask to infinity to de > facto disable interrupts", but that seems like a distinction > without a difference. > >>> 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. If we can s/taken/attempts/ in the first line of that paragraph:: 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). 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. > 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. > 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. > - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-24 12:37 +0000 |
| Message-ID | <vrrjlp$t52$1@reader1.panix.com> |
| In reply to | #111245 |
In article <4603ec2d5082f16ab0588b4b9d6f96c7@www.novabbs.org>, MitchAlsup1 <mitchalsup@aol.com> wrote: >On Thu, 20 Mar 2025 20:25:59 +0000, 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: >>>> In article <af2d54a7c6c694bf18bcca6e6876a72b@www.novabbs.org>, >>>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>>>On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote: >>>>>> In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>, >>>>>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>>>>>I want to address the elephant in the room:: >>>>>>> >>>>>>>Why disable interrupts AT ALL !! >>>>>> >>>>>> So that you can have some mechanism for building critical >>>>>> sections that span multiple instructions, where just having >>>>>> access to atomics and spin locks isn't enough. >>>>> >>>>>You can do this with priority, too. >>>> >>>> In the limit, disabling interrupts is just setting the priority >>>> mask to infinity, so in some sense this is de facto true. But I >>>> don't see how having a prioritization scheme is all that useful. >>>> Consider that when you're starting the system up, you need to >>>> do things like set up an interrupt handler vector, and so on; >>> >>>The Interrupt vector is completely software. HW delivers the MSI-X >>>message and the service for which this message is for, and SW decides >>>what to do with this message to that service provider. No HW vectoring >>>but HW does deliver all the bits needed to guide SW to its goal. >> >> Maybe I'm missing the context here, and apologies if I am. But >> which interrupt disable are we talking about here, and where? I > >We are talking about the core's Interrupt Disablement and nothing >of the gates farther out in the system that control interrupt >deliveries (or not). Ok, that's what I thought. >> am coming at this from the perspective of systems software >> running on some CPU core somewhere; if I want that software to >> enter a critical section that cannot be interrupted, then it >> seems to me that MSI-X delivery is just a detail at that point. >> I might want to prevent IPIs, or delivery or local interrupts >> attached directly to the CPU (or something like an IOAPIC or >> GIC distributor). > >All of those flow through the same mechanism; even a locally >generated timer interrupt. Right. So whether those interrupts come from MSI-X or anything else is mostly irrelevant. >>>> [snip/] >>>> 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. > >If we can s/taken/attempts/ in the first line of that paragraph:: If it has merely attempted, then it's a completely different scenario. Something that is more transactional in nature is no longer just a simple CAS-based spinlock. It may be _better_, but it is definitely different. >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). 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. >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. >> 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? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-24 13:59 +0000 |
| Message-ID | <pzdEP.126362$f5K3.26821@fx36.iad> |
| In reply to | #111262 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >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? Sounds a lot like transactional memory. Something that has yet to prove to be usable in the general case. > >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. Which can be done with compare and exchange, atomically; a lock may not be necessary. The insert into an ordered list will likely require a spin lock (or a reader-writer lock of some form).
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-24 17:47 +0000 |
| Message-ID | <24e503dc227d8b2bb0b68fd9ca8774b4@www.novabbs.org> |
| In reply to | #111263 |
On Mon, 24 Mar 2025 13:59:49 +0000, Scott Lurndal wrote: > cross@spitfire.i.gajendra.net (Dan Cross) writes: >>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? > > Sounds a lot like transactional memory. Something that has > yet to prove to be usable in the general case. It is not TM, but can be used to implement TM should you like. It is a set of instructions that can implement any (known) ATOMIC process (TestAndSet, TestAndTestAndSet; lock, unlock, LD-locked, ST-conditional, CompareSwap, CompareDouble, SwapDouble CompareTriple, SwapTriple, RemoveElement, InsertElement, MoveElement, ...} It is basically a recipe book so SW can implement whatever kinds of ATOMIC things SW wants, leaving HW out of the loop. you can also consider it a fully pipelined version of LDL and STC with up to 8 cache lines of data available for the event. >> >>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. > > Which can be done with compare and exchange, atomically; > a lock may not be necessary. > > The insert into an ordered list will likely require a > spin lock (or a reader-writer lock of some form).
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-24 18:49 +0000 |
| Message-ID | <vrs9g9$pnb$2@reader1.panix.com> |
| In reply to | #111263 |
In article <pzdEP.126362$f5K3.26821@fx36.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>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? > >Sounds a lot like transactional memory. Something that has >yet to prove to be usable in the general case. I understand that some mallocs have done it; McRT-Malloc from Intel, if I'm not mistaken. >>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. > >Which can be done with compare and exchange, atomically; >a lock may not be necessary. > >The insert into an ordered list will likely require a >spin lock (or a reader-writer lock of some form). I'm sure one could do a lockless pop using a cmp exchange, but I wanted to a scenario where one would want to hold onto both locks throughout the critical section for some reason. I just don't see how this works in the proposed scenario. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-24 12:12 -0700 |
| Message-ID | <vrsaro$1faj3$9@dont-email.me> |
| In reply to | #111270 |
On 3/24/2025 11:49 AM, Dan Cross wrote: > In article <pzdEP.126362$f5K3.26821@fx36.iad>, > Scott Lurndal <slp53@pacbell.net> wrote: >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >>> 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? >> >> Sounds a lot like transactional memory. Something that has >> yet to prove to be usable in the general case. > > I understand that some mallocs have done it; McRT-Malloc from > Intel, if I'm not mistaken. > >>> 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. >> >> Which can be done with compare and exchange, atomically; >> a lock may not be necessary. >> >> The insert into an ordered list will likely require a >> spin lock (or a reader-writer lock of some form). > > I'm sure one could do a lockless pop using a cmp exchange, but I > wanted to a scenario where one would want to hold onto both > locks throughout the critical section for some reason. > I just don't see how this works in the proposed scenario. You want to hold lock A while lock B us being used? That can be tricky. Well, there is a locking order. Check out this older work of mine, multex: https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/SkSqpSxGCAAJ Not sure if this is relevant or not.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-24 19:46 +0000 |
| Message-ID | <4EiEP.710132$2zn8.450635@fx15.iad> |
| In reply to | #111275 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 3/24/2025 11:49 AM, Dan Cross wrote: >> In article <pzdEP.126362$f5K3.26821@fx36.iad>, >> Scott Lurndal <slp53@pacbell.net> wrote: >>> cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>> 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? >>> >>> Sounds a lot like transactional memory. Something that has >>> yet to prove to be usable in the general case. >> >> I understand that some mallocs have done it; McRT-Malloc from >> Intel, if I'm not mistaken. >> >>>> 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. >>> >>> Which can be done with compare and exchange, atomically; >>> a lock may not be necessary. >>> >>> The insert into an ordered list will likely require a >>> spin lock (or a reader-writer lock of some form). >> >> I'm sure one could do a lockless pop using a cmp exchange, but I >> wanted to a scenario where one would want to hold onto both >> locks throughout the critical section for some reason. >> I just don't see how this works in the proposed scenario. > >You want to hold lock A while lock B us being used? That can be tricky. >Well, there is a locking order. Architecturally, we implemented locks in the hardware in the Burroughs V-Series mainframes. Each lock was assigned (by the programmer) a 'canonical lock number' (CLN) which was a four digit value between 0 and 9999. The CPU would track the currently active CLN and fault any lock instruction that attempted to acquire a lock with a CLN less than or equal to the current CLN. Unlocks would fault if the locks were not released in the reverse order. This guaranteed deadlock-free locking, but complicated the programming - with lots of locks, assigning the CLN to a particular lock was tricky. We used it in the operating system (four-cpu system) very successfully. There were similar instructions to implement condition variables with wait and signal semantics. A small microkernel was responsible for scheduling, if a lock was already held, the thread would be added to a waiting list and a runnable thread dispatched. microkernel interrupts were relatively low cost compared with normal interrupts. A single instruction was used to dispatch the next task (BRV - Branch Virutal Reinstate). When a lock was unlocked, and there was a pending waiter, the instruction would trap to the microkernel to handle the case and place the waiting thread on a runnable queue (by priority). When a lock acquisition failed because another thread owned the lock, the instruction would trap to the microkernel which would dispatch the next runnable task.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-24 20:14 +0000 |
| Message-ID | <vrsefn$siu$2@reader1.panix.com> |
| In reply to | #111275 |
In article <vrsaro$1faj3$9@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 3/24/2025 11:49 AM, Dan Cross wrote: >> [snip] >> I'm sure one could do a lockless pop using a cmp exchange, but I >> wanted to a scenario where one would want to hold onto both >> locks throughout the critical section for some reason. >> I just don't see how this works in the proposed scenario. > >You want to hold lock A while lock B us being used? That can be tricky. Really? This happens all the time. Of course it can be tricky, as concurrent programming always is, but it's incredibly normal. >Well, there is a locking order. Check out this older work of mine, multex: > >https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/SkSqpSxGCAAJ > >Not sure if this is relevant or not. It doesn't appear to be; sorry. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-24 19:02 -0700 |
| Message-ID | <vrt2sb$27c13$2@dont-email.me> |
| In reply to | #111278 |
On 3/24/2025 1:14 PM, Dan Cross wrote: > In article <vrsaro$1faj3$9@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 3/24/2025 11:49 AM, Dan Cross wrote: >>> [snip] >>> I'm sure one could do a lockless pop using a cmp exchange, but I >>> wanted to a scenario where one would want to hold onto both >>> locks throughout the critical section for some reason. >>> I just don't see how this works in the proposed scenario. >> >> You want to hold lock A while lock B us being used? That can be tricky. > > Really? This happens all the time. Of course it can be tricky, > as concurrent programming always is, but it's incredibly normal. Locking order comes into play here. Uggg... I have seen nightmare code that was using recursion as well... It deadlocked at a certain depth, only under the right conditions. The locking order was not properly respected... > >> Well, there is a locking order. Check out this older work of mine, multex: >> >> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/SkSqpSxGCAAJ >> >> Not sure if this is relevant or not. > > It doesn't appear to be; sorry. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-24 19:05 -0700 |
| Message-ID | <vrt323$27c13$3@dont-email.me> |
| In reply to | #111285 |
On 3/24/2025 7:02 PM, Chris M. Thomasson wrote: > On 3/24/2025 1:14 PM, Dan Cross wrote: >> In article <vrsaro$1faj3$9@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 3/24/2025 11:49 AM, Dan Cross wrote: >>>> [snip] >>>> I'm sure one could do a lockless pop using a cmp exchange, but I >>>> wanted to a scenario where one would want to hold onto both >>>> locks throughout the critical section for some reason. >>>> I just don't see how this works in the proposed scenario. >>> >>> You want to hold lock A while lock B us being used? That can be tricky. >> >> Really? This happens all the time. Of course it can be tricky, >> as concurrent programming always is, but it's incredibly normal. > > Locking order comes into play here. Uggg... I have seen nightmare code > that was using recursion as well... It deadlocked at a certain depth, > only under the right conditions. The locking order was not properly > respected... A thread would take mtxA, then mtxB, while another would take mtxB, then mtxA. Deadlock city is going to be visited rather soon... > > >> >>> Well, there is a locking order. Check out this older work of mine, >>> multex: >>> >>> https://groups.google.com/g/comp.lang.c++/c/sV4WC_cBb9Q/m/SkSqpSxGCAAJ >>> >>> Not sure if this is relevant or not. >> >> It doesn't appear to be; sorry. >> >> - Dan C. >> >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 11:17 +0000 |
| Message-ID | <vru3d6$kna$1@reader1.panix.com> |
| In reply to | #111286 |
In article <vrt323$27c13$3@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 3/24/2025 7:02 PM, Chris M. Thomasson wrote: >> On 3/24/2025 1:14 PM, Dan Cross wrote: >>> In article <vrsaro$1faj3$9@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 3/24/2025 11:49 AM, Dan Cross wrote: >>>>> [snip] >>>>> I'm sure one could do a lockless pop using a cmp exchange, but I >>>>> wanted to a scenario where one would want to hold onto both >>>>> locks throughout the critical section for some reason. >>>>> I just don't see how this works in the proposed scenario. >>>> >>>> You want to hold lock A while lock B us being used? That can be tricky. >>> >>> Really? This happens all the time. Of course it can be tricky, >>> as concurrent programming always is, but it's incredibly normal. >> >> Locking order comes into play here. Uggg... I have seen nightmare code >> that was using recursion as well... It deadlocked at a certain depth, >> only under the right conditions. The locking order was not properly >> respected... > >A thread would take mtxA, then mtxB, while another would take mtxB, then >mtxA. Deadlock city is going to be visited rather soon... Yeah, so don't do that. :-) I can whack myself in the head with a ballpeen hammer, too. It is better if I do not. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-25 11:14 +0000 |
| Message-ID | <vru36r$ja1$1@reader1.panix.com> |
| In reply to | #111285 |
In article <vrt2sb$27c13$2@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 3/24/2025 1:14 PM, Dan Cross wrote: >> In article <vrsaro$1faj3$9@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 3/24/2025 11:49 AM, Dan Cross wrote: >>>> [snip] >>>> I'm sure one could do a lockless pop using a cmp exchange, but I >>>> wanted to a scenario where one would want to hold onto both >>>> locks throughout the critical section for some reason. >>>> I just don't see how this works in the proposed scenario. >>> >>> You want to hold lock A while lock B us being used? That can be tricky. >> >> Really? This happens all the time. Of course it can be tricky, >> as concurrent programming always is, but it's incredibly normal. > >Locking order comes into play here. Uggg... I have seen nightmare code >that was using recursion as well... It deadlocked at a certain depth, >only under the right conditions. The locking order was not properly >respected... Well, of course it does. But it's still something that people do all the time. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-25 13:32 -0700 |
| Message-ID | <vrv3t5$3ekk$1@dont-email.me> |
| In reply to | #111291 |
On 3/25/2025 4:14 AM, Dan Cross wrote: > In article <vrt2sb$27c13$2@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 3/24/2025 1:14 PM, Dan Cross wrote: >>> In article <vrsaro$1faj3$9@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 3/24/2025 11:49 AM, Dan Cross wrote: >>>>> [snip] >>>>> I'm sure one could do a lockless pop using a cmp exchange, but I >>>>> wanted to a scenario where one would want to hold onto both >>>>> locks throughout the critical section for some reason. >>>>> I just don't see how this works in the proposed scenario. >>>> >>>> You want to hold lock A while lock B us being used? That can be tricky. >>> >>> Really? This happens all the time. Of course it can be tricky, >>> as concurrent programming always is, but it's incredibly normal. >> >> Locking order comes into play here. Uggg... I have seen nightmare code >> that was using recursion as well... It deadlocked at a certain depth, >> only under the right conditions. The locking order was not properly >> respected... > > Well, of course it does. But it's still something that people > do all the time. Indeed. :^) I have had to debug nightmare code from "other" people... What a bitch!
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-24 17:36 +0000 |
| Message-ID | <33d525dc9450a654173f9313f0564224@www.novabbs.org> |
| In reply to | #111262 |
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 ...
>
> 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.
> - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web