Jump to content

CLNs and threading


asbo

Recommended Posts

I'm having a go at implementing some of the Windows Sockets API and run into the same issue Rolf talks about in this post:

Quote

Just one more comment. The error handling with WSAGetLastError() is probably never gonna return a meaningful error. (WSA)GetLastError() retrieves a thread local storage value set previously by another function. That assumes that the previous function and GetLastError() are called in the same thread and without any other function in between that could set that value. Since the CLN's are set to execute in any thread this is absolutely impossible to guarantee and in my experience actually almost never happens either.

Not even setting both CLNs to execute in the UI execution system would be able to guarantee proper operation, since theoretically there could still execute another call to an API that influences this value, between when LabVIEW calls the recv() function and when it eventually calls the WSAGetLastError().

My issue is a little more fine-grained, perhaps. If I have my two CLNs SomeWSACall() and WSAGetLastError() on the same block diagram, happy days - I get my socket error code. However, I wrapped that WSAGetLastError() call into a subVI and now it doesn't work! Evidently, using a subVI ensures that something, somewhere makes a call to WSASetLastError() in the UI thread. I did open a support issue with NI about it, but I expect they'll tell me what I already know.

Why is it that we do not get the fine-grained thread control for CLNs as we do for VIs - or is it that "execution systems" in LabVIEW are not explicitly threads?

Though I'm referring to specific functions, this is really more broad - I will probably be working with several other Windows APIs in the future and it would be helpful to have a complete grasp of the nuances here.

Link to comment

Why is it that we do not get the fine-grained thread control for CLNs as we do for VIs - or is it that "execution systems" in LabVIEW are not explicitly threads?

The execution systems consist of a number of (typically 4...up to 8) threads. In this respect, you are specifying a smaller "pool" of threads that labview should use for a particular VI or set of VIs rather than explicitly defining which threads things run in.

Edited by ShaunR
Link to comment

The execution systems consist of a number of (typically 4...up to 8) threads. In this respect, you are specifying a smaller "pool" of threads that labview should use for a particular VI or set of VIs rather than explicitly defining which threads things run in.

That solidifies one part of it ... I expect that if I'd opened up the help file, it would have been right there waiting for me. Thanks nonetheless.

Does anyone have any feedback on the balance of my questions?

Link to comment

LabVIEW doesn't know how long any specific CLN will take to execute, so we assume that they will all take long enough to be worth scheduling in parallel with other code (clumping separately). This increases the chance of multiple CLNs not running in the same thread. However, there is a solution. Subroutine VIs come to the rescue. Subroutines always generate a single clump and will execute all their code in a single thread. So as long as your socket call and the getlasterror are made under the same subroutine, they will execute in the same thread. This even covers the case where the getlasterror is encapsulated in other subroutine VI for reuse.

There is one extreme corner case where other code could be run between the 2 calls. It involves the subroutine starting cooperatively in a thread under a call to a LV built DLL. The vast majority of applications don't even create this situation and it is pretty unlikely to happen even in those that do.

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.