How to pass Mutex owning to a sub-VI ?

[snicolay]

Hello,
I used to do the following in C (LabWindows for example):
Function MyWrite
LockMutex
doTheWrite
UnlockMutex
End

Function MyRead
LockMutex
doTheRead
UnlockMutex
End

Function MyQuery
LockMutex
call MyWrite
call MyRead
UnlockMutex
End

In this example, when calling MyQUery, the MyQuery is owning the Mutex, so the locks in MyWrite and MyRead are transparent because called in the same thread, the thread that is owning the Mutex.
I tried to do the same into LabView, but when calling MyQuery, the LockMutex (in fact, the vi AcquireMutex) of MyWrite is waiting for the Mutex to be freed. It doesn't understand that the ressource has been locked a step upper and that it doesn't need to wait.
Why ?
How can I use the Mutex as I used to do in C ?
Thank you very much.

[M_Kunze]

Hi.

As far as I know there is no real mutex in LabView.

If you just want to know if a VI is running than you can
do a VI-Reference and use a method to find out.
If the method is true than your VI is still running.
It might be nessesary that you load the VI dynamicaly
and start it.

I think that will work.

With kind regards

Martin

[snicolay]

Thank you for your answer Martin, but I don't think it can help me.
In fact, I need that none thread can interrupt the sequence. I need that Mywrite and MyRead are executed in a single operation when called from MyQuery. And I still don't know how to do that.

[tst]

LV has built in synchronization tools, in the Advanced>>Synchronization palette. Have you tried looking at them?
Most of them can be used as mutexes. As an example, for a locked global variable, you can use a single element queue. If every time you access the queue you start by emptying it (and set the timeout to -1), then every VI accessing the queue will have to wait until whoever called it first puts the element back in the queue before manipulating it (the credit goes to DFGray).

[Ben]

Semaphores can be used as mutexes.....

But ther is a much easier way to do this!

An "action engine" in LV is a VI that will operate in a manner that is controlled by the called. They can be of varying complexity but a simple version can be developed by using an "enum" to control the "action" (i.e. Read, Write, R/W, etc). Each action being realized as a uniue case of a case structure that is driven by the enum.

How this is simpler:

Unless you specify otherwise, LV VI's are non-reentrant. In LV this means that the VI can only be executed by one thread of code at a time.

If the VI is being used by one thread and another thread attempts to use it, the second thread will stall until the first completes.

Behind the scenes LV uses mutexes to control access to the sub-VI.

So...

If you create an action engine that performs all of your R/W work and use it as the only method for touching the resours in question, then LV will do all of the mutex work.

Now if you really want to do it the way it is done in C, then you should look at the semaphore VI's.

I hope you really do not want to do that. If you do, post some follow-up Q's after reviewing those VI's.

Trying to help,

Ben

[snicolay]

Thank you very much for your help, I already used these "actions enum" for other things, but I can't use this way to solve my Mutex problem, because there are other cases as this one:

I have a "Write" function that can be called from several threads, and that uses a global variable that is protected by a a LabView semaphore (because this global appears in other functions, the non-rentrant configuration isn't enough).
The fact is that one thread has to perform 3 or 4 "Write" operations and the global variable must not be modified between these calls.
In C language, a simple manner to do that would be to protect the calls of this multiple write operation by the Mutex of the global variable itself.
But in LabView, it seems it doesn't work because when the Mutex (in fact the semaphore vi) has been taken before the first call of the "Write" function, then the "Write" function (that also need the Mutex to access the variable) waits forever...
I have no idea at this time...
Thank you

PS: for info, if this can help, I am using LV 7.1 RT.

[tst]

Well, that's one of the problems with writing in parallel.
It sounds like you need an additional mutex for places where you have a series of writes. You can design this as a typedef enum where each VI can only access the global if this mutex is of a certain value. It sound like a bit of kludge, and like a major potential for race conditions, but that's just an answer of the top of my head. Maybe someone else has a better solution.
Incidentally, what's the point of having to write to a global several times in a row? Maybe you should look into a different type of solution (since it's one thread, why not use a wire, and so on?).

[Ben]

Please examine the attached example (LV 7.1).

It demonstrates how all operations associated with a shared resource can be encapsulated using an action engine.

In this example I have three loops running a 1000Hz.

Two of the loops increment the "global" by "1".

The third watches this same global.

After completing, it will display the final count of the number of iterations for the two writing loops. The result will check with the number of iterations of the two "updating" loops.

The critical methodology used here is to make sure all operations that involve mod's of the Global occur inside the sub-VI.

Please let us know if you have follow-up Q's.

Ben

NOTE: NO race conditions, NO semaphores.

Message Edited by Ben on 06-03-2005 11:58 AM

[snicolay]

Thank you all. Finally I have changed my design in order to avoid the disturbing cases. Thank you for your contibution.