New Process exclusion Semaphore in Labview

[manu.NET]

Hello,

The Labview Build in Semaphore is a "Software Semaphore" created with a simple Queue.

I would like to have a Semaphore which could be abble to manage exclusion between "Threads, Process, Compilation units".

Actualy, the build in Semaphore can't be taken twice by a same process, Thread, Compilation Unit, because it doesn't take in account the process which has tryed to take it.

You can easily test it by creating a simple VI which calls twice a "Semaphore take" ... you will "deadlock yourself" !

I would like to have a "One token Semaphore or MUTEX", which could be taken multiple times by the owning process. 

My need was at the begining, to made an existing instrument driver to be thread safe ... without having to create a "Gaz factory"  and to modify an existing application architecture !

So i started all the VI's of the instrument driver, with a "Take semaphore", and finished them with a "Release Semaphore" ...

But some of the VI's where called by others ... and then => DeadLock !!!!

The solution would be to place in an intellignet way the Take and the release ... but i am sure i will forgot some special cases ....

So the idea of a new "Process/Thread/Compilation Unit MUTEX".

The behaviour of the new Semaphore will be quite the same as the existing one, the only diffirence is that the owning process,thread or compilation unit, will have the right to take a Semaphore more than one time without creating a Deadlock.

I think that the behaviour i describe here, is the behaviour in most of the existing real time systems like WxWorks, IRMX, OS9 ...

It would be nice to have such a tool, in order to simplify The ressources exclusions !

Manu.net

[GregR]

Reentrant mutexs versus non-reentrant mutexs is a common computer science issue. In an explicitly threaded system a reentrant mutex is claimed for a thread allowing multiple acquires to be nested. Fans of both approaches exist. The problem is that implementing a reentrant mutex in an implicitly threaded system (like LabVIEW) is hard to define.

In LabVIEW a subVI does not necessarily run in the same thread as its caller. There could be parallel code that caused us to schedule into another thread, so we can't use the thread to decide if a second acquire is valid. What if a subVI that does not have the mutex calls 2 subVIs in parallel that both acquire the mutex? Should these acquires be serialized? I would think yes, but maybe you disagree. What if the caller adds an acquire? Should the subVIs then be able to run in parallel? They could be doing completely different things to the hardware. What if there is not an explicit ordering between the acquire in the caller and the subVI calls? This might mean that sometimes the caller acquires first and everything runs in parallel. If the caller doesn't though, does that mean one of the subVI could claim the mutex and the caller would have to wait for them?

There may be a solution that creates consistent behavior for all these cases, but it is very complicated to understand those interactions so there is a good chance the end result would not be what the user intended. In the end we came down to the same argument always used for non-reentrant mutexs. It is better to refactor your code to avoid reentrant acquires than to open yourself up to the differences in behavior that can happen with reentrant mutexs. In the case of your instrument drivers that means creating a public layer that all acquire the mutex and never calling a public layer VI from the driver itself. In any case where a public VI would want to call another public VI, move the functionality to an internal VI that assumes the mutex has already been acquired and have both VIs call it.

[manu.NET]

Thanks for your answer,

I understand the problem.

I have already modify my program architecture in order to not have to use any Semaphore.

=> Only one process can access the instrument driver. All commands are send to him threw events.

Manu.net. 

[AristosQueue (NI)]

GregR's point was that you didn't have to refactor -- just have the Semaphore only be acquired by your public VIs, not your private subVIs. Mark them as private so no one can invoke them outside of your driver. The events layer is likely an unnecessary expense. On the other hand, since you've got it working now, I wouldn't refactor again unless you find another issue caused by the event model.

[manu.NET]

Hello Aristos Queue,

I have to refactor the code because there is no difference between Public and Private VI's ...

All the VI's can be called ... and are called ...

So the problem is how placing in an intelligent way the Semaphore ... This is difficult to answer ... and the risks are big.

The problem is, that the application i currently modify is not mine ... So i don't have a global view of the problem.

So i refactor the application ... and i think it is safer now ! Before it was a problem of bad architecture !

Thanks.

Manu.net

[AristosQueue (NI)]

Ah. That's a different issue. 🙂

[G-Money]

Declined. See GregR comments for more on the reasoning.