Do the handles passed to a dll have to be locked down to insure other threads don't move the data?

[Eric6756]

This question generally applies to the situation when you've dereferenced a LV handle in a dll written in C and are manipulating the associated data with a pointer, usually in a loop.

Somewhere I read, in the Microsoft Visual Studio documentation I think, that in general you don't have to worry about locking down handles to insure the associated pointer remains valid for the duration of its use. But I'm not sure of the context in which the statement was made. Obviously, this is true for single threaded synchronous code since every application gets a unique memory space.

It would seem though in a multithreaded environment, unless each thread also gets an associat
ed memory space, that other threads could potentially cause the data associated with a handle to be moved. At least, that's what I would assume.

Could someone please clarify this?

Thanks,
Eric

[Ben]

Hi Eric,

Its me again. I belive you are correct. I do not think I am qualified to clarify.
After watching you go back and forth with Greg previously I think I have have something for you that you will just love.

This link will get you to Brian Reken's search engine. If "un-check" the "web" box, this enginewill search all of the "info-LabVIEW" archieves for what ever you specify. I suggest you search on "Rolf Kalbermatter" and or "Greg McKaskle".

http://www.searchview.net/

Info-LabVIEW is where all of the "heavy-hitter" in labVIEW have been havingdiscusions like this for years. I have "eaves-dropped" on that list for years. I belive I have read Rolf speaking on this topic.

If you already knew about this resouce, please excuse me.

Ben

[Greg_McKaskle2]

....
> It would seem though in a multithreaded environment, unless each
> thread also gets an associated memory space, that other threads could
> potentially cause the data associated with a handle to be moved. At
> least, that's what I would assume.
>

LV handles don't have to be locked. The LV generated code prevents
multiple pieces of code from running at the same time that will affect a
wire. A wire has only one writer, and the readers of the wire cannot
execute until the write has completed execution. Also, LV handles are
not the same as Windows handles. A handle can be reallocated when it
grows or shrinks, but it will not cause other handles to move. At the
lowest level, you will find that there are functions for locking and
unlocking
AZHandles, but DSHandles are prelocked and never move. Plus
in the years that have passed since the memory manager was written, even
the AZ handles have stopped being compacted except on one platform,
classic macs.

Greg McKaskle

[Eric6756]

Ben,

Thanks, I didn't know.

Kind Regards,
Eric

[Eric6756]

Greg,

I haven't played with handles since university, on, in fact, classic Macs.

In answering my question you made these points.

(1) LV handles are not windows handles.

Your point is that labVIEW has a completely separate memory management system different from the OS. You cannot use the OS API utilities to lock or unlock handles. All memory management functions, allocation, resizing, locking, and disposing, must be done via the LV library.

This is wholly different than assuming that the handles are actually windows handles. If you assume that, you assume that the LV memory management functions utilize the windows memory manager to perform basic functions, and that the LV memory management library functions primary purpose is to maintain
addition data required by LV. This assumption still requires you use the LV functions, but also implies you could use the API to lock or unlock handles. Obviously WRONG!

(2) LV DSHandles are prelocked and never move unless resize. AZHandles have stopped being compacted.

I would have to conclude that most of the problems with memory fragmentation went away with hardware memory mapping... As years have passed since I've actually worked in this arena, I guess I should find some documentation to bring me up to date. Any suggestions there would be appreciated.

Thanks,
Kind Regards,
Eric

[Greg_McKaskle2]

> Your point is that labVIEW has a completely separate memory management
> system different from the OS. You cannot use the OS API utilities to
> lock or unlock handles. All memory management functions, allocation,
> resizing, locking, and disposing, must be done via the LV library.

If AZ or DS handles are passed to a windows function dealing with
handles, you will likely get back an error. LV handles are faster and
more specialized than the windows ones. The documentation in the
external functions manual will cover some of the details. You should
find additional info on devzone.

Greg McKaskle

[Eric6756]

Greg,

I noticed I can also generate errors in the LV functions when I do stupid things.

Thanks,
Kind Regards,
Eric

[Eric6756]

Ben,

I've been looking at your suggested site and it does contain a lot of information. I particularly like the articles at:

http://www.wideman-one.com/gw/tech/dataacq/index.htm

They are very thorough.

It is a site well worth investigating,
Thanks again,
Kind Regards,
Eric

[Ben]

Hi Eric,

I started out giving you "half-as*%#" answers, and you come back with this interesting link that I had not noticed.

Talk about getting something for nothing (what it that the 1st law of thermodynamics?)!

Thank you Eric, I'll add that site to my reading list.

I am indebted to you (like many others on this exchange)now,

Ben

[Eric6756]

Hi Ben

When you�re done there, and before you decide to track down all those links, come back and read NI Application Note 114. There is a lot of information there too, but it�s kind of confusing. In particular the statement "Each of the execution systems has a separate execution system for each priority level,..." seems a bit recursive, causing potential cerebral overflow. In the end, I found I had to tabulate the execution systems, and their associated priorities, threads, and queues, so that I could keep things straight. (If you follow that up with a search here on "Execution Systems" you will find some of Gregs comments too.)

When your reading app. note 114, pay particular attention to the fact that some nodes must, and some no
des may, execute in the user interface thread regardless of the vi settings; those that may depend on the polymorphic node variant your using (in other words, how you wire the node.)

And when you think you have that straight, go back to your original site and read what Greg has to say about property nodes.

At the moment, I'm wondering where I'm going to find a summary list of all the nodes and their associated threading restrictions, and how they may affect my diagrams�

Maybe Dr.vi would consider composing a mini-series on the LabVIEW execution model.

Anyway, a problem hit my desk a couple days ago. Apparently on one of our systems, my boss was trying to print 30 pages in about a minute and found, despite my hopeful threading model, it was interfering with DAQ. I thought I was a stress tester, but he really gets into it. Anyway, I think my printing must be executing on my DAQ thread since it has top priority�

I've really got to go play, work, or something...

Th
anks Ben,
Kind Regards,
Eric