Problem calling more than one instance of a dll doing a InetTelnetOpen

[TiWi]

Thanks, just what I wanted to know 😉
Is there any documentation somewhere to know which libraries are multithreading safe and which are not?

Thanks

[LuisG]

All the standard CVI libraries have been multithread-safe since version 5.0. But keep in mind the point that Mohan made: they all restrict access to their functions to no more than one thread at a time.

Luis

P.S. If you're interested in some more in-depth discussion of multithreading in CVI, there's a document that delves into multithreading issues in some detail. To view it, launch the CVI bookshelf (click "Help>>LabWindows/CVI Bookshelf") then click on "Application Notes and White Papers", and then click on "Multithreading in LabWindows/CVI" (not "Building Multithreaded Applications with LabWindows/CVI"!)

[TiWi]

Yes I have read this document and it was very enlightening and well written. So you say that the libraries of LabWindows are multithread-safe and yet NI restrict them to only 1 thread at a time, why is that? After reading the multithreading document I would have expected the NI developers to be able to lock down some part of their code without restricting the whole library 😉

Thanks!

Louis

[LuisG]

You would think, wouldn't you? 🙂

The truth is that the complexity level of attempting that approach was just too high. Far too much code had been written, prior to when multithreading was a concern, for that approach to be feasible. This was the only way the libraries could be made thread-safe.

Luis

[TiWi]

Yeah I understand how complex code can become 😉
So in your opinion do you think that, if I ever would like to code my own InetTelnetRunscript from scratch with the TCP library (to be able to run some kind of prompt/reply array on a Telnet server), the function would be easily made tread safe?

Thanks!

Louis

[LuisG]

Yes, I believe you could implement your own version of that function, using InetTelnetReadUntil and InetTelnetWrite to handle the individual items in the script.

You can certainly make that function thread safe by simply using only local variables. If you do have to use global variables, you can still make sure that each thread has its own copy of each variable by using thread-locals (see samples\utility\threading\ThreadLocalVar\ThreadLocalVar.prj).

Luis

[Mohan]

Trying to make a function like InetTelnetRunScript callable by multiple threads simultaneously has the following issues:
1) It should lock on a per-telnet-handle basis - if not you will end up sending junk to the telnet server.
2) If you lock it on a per-telnet handle basis, then really you should call it from the other thread with a different telnet handle for the "threading" to be useful. If not, you are still going to get the behavior you see now.
3) In my view, using InetTelnetRunScript in this situation (you want the telnet server to execute multiple commands in parallel) may not be appropriate. Instead, I would think that each thread should call InetTelnetWrite and InetTelnetRead (NOT InetTelnetReadUntil) with thread-specific telnet handles to get parallel behavior. Also, the InetTelnetRead should read in very small chunks to prevent one thread from waiting on TCP data for too long and blocking out the other threads (same reason not to use ReadUntil). Note that this should result in parallel behavior because even though there is a library lock, the various threads should be able to grab that lock alternately and maintain multiple telnet sessions.
4) If you want to write your own implementation then you may have to use something more low-level than the CVI TCP library because that library also locks on a library level and so you will pretty much have to do 3 using TCP handles instead of Telnet handles - I cannot see any additional benefit in doing this.
5) If you write your own implementation using something like Windows sockets, then the only benefit you get over 3 (and 4) is that you can read in larger chunks. But this is not always feasible because anyway you need to examine every byte for control codes, etc because of the nature of the telnet protocol. You may be able to estimate the number of bytes to read for some commands and then read in larger chunks there and save some time - but I am not sure if this is worth doing or even that it can be cleanly implemented.

So, I would recommend 3.

Best regards,
Mohan

[TiWi]

Thank you for taking the time to go into such details. I've made a first implementation of solution #3, I just haven't had time to test it yet. I'll get back to you guys once this is done. Thanks!

Louis