memory position of numpy arrays

Lars Friedrich lfriedri at imtek.de
Tue Oct 24 00:40:41 CDT 2006


Andrew,

thanks for your fast answer.

Am Montag, den 23.10.2006, 00:45 -0700 schrieb Andrew Straw: 
> It sounds like your hardware drivers may be buggy -- you should only get
> segfaults, not (the Windows equivalent of) kernel panics, when your
> userspace code accesses wrong memory.

When I started to write this thing, I had a lot of bluescreens. I think
they occured when my Python program and the hardware driver were
accessing the same memory location at the same time. I think the
hardware uses some DMA-technique.

> But if you have buggy hardware drivers, I suppose it's possible that
> locking the memory will help. This wouldn't be the domain of numpy,
> however. In Linux, this is acheived with a system call such as mlock()
> or mlockall(). You'll have to figure out the appropriate call in
> Windows. Thinking about it, if your hardware drivers require the memory
> to be locked, they should do it themselves.

I am not really sure about the term "locking". Does that mean that this
part is not paged, or that this part is not accessed by two entities at
the same time? Or both?

Would I do these mlock()-calls in my C-Dll? If Yes, what would happen,
if I tried to access the numpy-array from python, during the time it is
locked?

> However, I'm not convinced
> this is the real issue. It seems at least equally likely that your
> hardware drivers were developed with particular pattern of timing when
> accessing the buffers, but now you may be attempting to hold a buffer
> longer (preventing the driver writing to it) than the developer ever
> tested. It shouldn't blue-screen, but it does...
> I think it quite likely that you have some buggy hardware drivers. What
> hardware is it?

It is a camera with its own PCI-frame-grabber card. I am using it in
"continuous-acquisition-mode" so I suppose, the driver is ready for
*long* uses... Anyway, if the bluescreens continue I will have to switch
to the "single-frame-acquisition-mode" and prepare a single buffer for
every frame to grab.

Of course, there would be a different way: I could allocate the buffer
in C, in the dll. After data retrievel using the hardware API I could
then copy the data to some numpy-array, still using C. But this would
make my C-coded dll longer, thus harder to maintain.

Is my way a common way? I mean, letting python/numpy do the memory
allocation by creating a numpy-array with zeros in and passing its
memory location to the hardware-API?

Thanks

Lars

-- 
Dipl.-Ing. Lars Friedrich
Optical Measurement Technology
Department of Microsystems Engineering -- IMTEK
University of Freiburg
Georges-Köhler-Allee 102
D-79110 Freiburg
Germany

phone: +49-761-203-7531
fax:   +49-761-203-7537
room:  01 088
email: lfriedri at imtek.de


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion


More information about the Numpy-discussion mailing list