Jos sanotaan että sinulla on 478kpl erillistä DMA-autoinit-muistisiirtoja yhtäaikaa menossa...

Käyttäisin assosiatiivisia kontekstiivejä. Ei tarvitse edes huolehtia sulkemisesta kun Python manageroi sen puolestani.

Käyttöjärjestelmä välissä - et käytännössä mitenkään, koska käyttäjän prosessi voi joutua ajosta pois yllättävän pitkäksikin aikaa. Linuxissa oli aikanaan 100 Hz kernel tick, eli prosessi saattoi vaihtua 100 kertaa sekunnissa. Nykyisin responsiivisissa järjestelmissä tuo voi olla 1000Hz. Aika usein systeemi on kuitenkin tickless eli tuolla ole juurikaan enää merkitystä.
No, DMA-siirrot ovat sitten keskeytys-ohjattuja esim. scatter-gather patternin kautta toimivia eli kernelillä on taski hoitamassa DMA-siirtojen aloituksia ja lista odottavista siirroista, taski ryhmittelee niitä ja käyttäjällä ei ole oikeastaan mahdollista vaikuttaa kuin alkutietoihin. Voi odottaa siirron valmistumista prosessissa, jonka jälkeen taski ilmoittaa käyttäjäprosessin olevan skeduloitavissa parhaassa tapauksessa uudelleen heti. DMA-siirroissa on yleensä kaksi moodia eli puskurin siirto ja non-stop. non-stop tarkoittaa, että puskuria käytetään uudelleen ts. alue muistista siirretään oheislaitteelle kerta toisensa jälkeen - tällainen on hyvä esim. audion siirrossa äänikortille. Puskurin siirto taas toimii verkkokortin kanssa hyvin eli paketti siirretään verkkokortille.
Jos siis pitää saada tarkasti haltuun DMA-siirron loppukohta, joutuu kirjoittamaan melko varmasti kernel-ajurikoodia ja mm. opettelemaan em. patternin käytön. Python on melko varmasti väärä tapa lähestyä asiaa, vaikka dataa voikin lähettää DMA-siirtoa tukevalle laitteelle silläkin?

Paras virheilmoitus minkä joskus saanut: DMA overrun error.... starting designated debugger, flipping to Windows core assembly-code....

"Warning! You can modify with that Visual C debugger even Windows core, like everything in real running time, but beware: if you change directly running assembly code, code will run for some time, but eventually crash"

"If it is important to save your data and so... modify running assembly code as you can do" _:D

Critical error in Direct Memory Access channels, reported by motherboard, even conflict with DMA-0 memory refress timer, what are you doing with your c-code there, Windows CRT-stopped your program running from this critilcal error..

... starting Visual C debugger, in assembly...

JA korjasin tosiaan, tuo debuggeri, VC-debuggeri näytti että vbäärä pointterisi, noh korjasin suoraan näpyttelemällä assembly-koodia jotta toimii sen aikaa tuo ohjelmani :D Jotta se pystyy ottamaan datat ytalteen :_D