Is it possible to achieve the same effect as pthread in Labview?

[Heartnode]

For an simple example in my given C code:

a struct

{

pthread_mutex;

pthread_cond;

member1

member2

}

threads-A:

pthread_lock(mutex)

while( simple-condition-function(member1) == true ){

       pthread_wait(mutex,cond);

}

// do something using member1 and member2

pthread_unlock(mutex)

threads-B:

pthread_lock(mutex)

//do something here;

pthread_unlock(mutex)

pthread_signal(cond);

At present I am trying to study on possible utilities to reach the same goal in LabView within two or three while-loops.

But things seems to be a bit difficult for me now and could you please give some hints or ideas about this, even tell me this is not possible(a little sad). Thank you!

[natasftw]

Place the code parallel such that it doesn't depend on the other bit of code.  It'll run in parallel threads.

Are you looking to expose some functionality built into specific hardware?  Or, are you seeking to just run multiple threads in your application?

[altenbach]

As has been said, graphical dataflow programming is automatically parallel and mutithreaded (except for the UI thread), but you can also easily have critical sections (e.g. a non-reentranst subVI) and protection from concurrent access to shared resources.

Instead of listing abstract code, can you explain in simple words what you are actually trying to do? What's the purpose of the program? What's in each while loop? Are you trying to solve a performance problem?

Can you show us your LabVIEW attempts and explain what it should do?

(A well written LabVIEW program can take full advantage and scale linearly with the number of processor cores . Example)

[Heartnode]

---

@altenbach  已写:

As has been said, graphical dataflow programming is automatically parallel and mutithreaded (except for the UI thread), but you can also easily have critical sections (e.g. a non-reentranst subVI) and protection from concurrent access to shared resources.

Instead of listing abstract code, can you explain in simple words what you are actually trying to do? What's the purpose of the program? What's in each while loop? Are you trying to solve a performance problem?

Can you show us your LabVIEW attempts and explain what it should do?

(A well written LabVIEW program can take full advantage and scale linearly with the number of processor cores . Example)

---

OK. I should have provided more details......

In a simple case, I guess there are several global variables shared among a number of threads and synchronization must be thought carefully. It is possible for every thread to access these shared variables. However, thread-1 will first lock these shared variables then use them to check if current condition is satisfied or not. If unsatisfied, thread-1 will fall asleep ,wait for awakening signal and unlock variables immediately within an atomic operation and of course thread-1 will continue if satisfied.

Thread-2 gains an ability to lock and modified shared variables then signaling to other threads which are waiting.

Thank you for mentioned the hints of "critical sections" and "non-reentranst subVI" and I will learn that and try again.

[Heartnode]

---

@natasftw  已写:

Place the code parallel such that it doesn't depend on the other bit of code.  It'll run in parallel threads.

Are you looking to expose some functionality built into specific hardware?  Or, are you seeking to just run multiple threads in your application?

---

Actually there seems to be some parameters shared among parallel loops and synchronization of data must be handled carefully.

See my replying above.

Thanks for your advice

[billko]

I've never used semaphores before, but this seems like a place they could be used.

[cbutcher]

Are you calling into a non-threadsafe external library (e.g. DLL)?

If not, I expect there might be easier (or at least "more LabVIEW-y") ways to accomplish your goal (on desktop - if you're using e.g. FPGA this might be a different answer) than careful use of semaphores/mutexes to block or enable various threads.

A particular example close to what you're already considering might be the use of an Action Engine. This is a more developed 'Functional Global Variable' (or LV2-global, based on their origin version), in which a non-reentrant VI is used to block simultaneous use in multiple threads, and a series of possible 'Actions' are exposed via a (usually typedef'd) enum.

This can take care of the atomicity of your operations if you use it in that way - no semaphores/explicit mutexing required (the subVI essentially forms the mutex).

If you need to handle the sequencing of multiple actions one after another, it may be that your needs are more focused on sequencing than asynchronous thread management. Many common architectures/designs address this kind of problem, but the State Machine is probably the simplest general idea. Of course if your operations are really asynchronous (as opposed to happening in different threads, but one after another) this would be more complicated to handle, to such an extent that a different structure would probably be better.

Can you try and describe a bit more how your operations are interlinked and their ordering/parallelism?