LV Threads, Monitors

[Joseph Oravec]

Hi,

I am trying to solve something like a producer-consumer problem in Labview
(thinking about Mesa-style monitors) but having a problem. It does not seem
like the Notify VIs can atomically release a lock and go to sleep.

Am I missing something?

-joey

[MichaelAivaliotis]

Why is the Notifier not working for you?
If you want the "wait on notification" vi to sleep then do not wire the timeout value. Otherwise the wait function will timeout and wake-up at the specified timeout value.

I have a presentation on synchronization techniques which should help, download it here:
http://www.mmwis.com/files/PDF/Knowledge_Base/LUGO10312001.pdf

The example code for this presentation is available as well:
http://www.mmwis.com/files/PDF/Knowledge_Base/LUGO10312001.zip

Michael Aivaliotis
mmWave Integrated Solutions Inc.
michael@mmwis.com

[Joseph Oravec]

"valiot" wrote in message
news:5065000000050000008A4B0000-1004225886000@exchange.ni.com...
> Why is the Notifier not working for you?
> If you want the "wait on notification" vi to sleep then do not wire
> the timeout value. Otherwise the wait function will timeout and
> wake-up at the specified timeout value.

Indeed, that works fine. I guess I should have been more specific. My
understanding of Mesa-Monitors (just school, I am no expert) is that you
must hold a lock before you wait() for a condition variable, and then wait()
should atomically release then wait for the condition variable. That way
whatever you signaled is blocked until after the wait() is complete.

The problem becomes that I can implement locks with semaphores, and I can

implement wait/signal with notify VIs, but I don't see how I can atomically
release a lock and wait().

It is of course possible to signal, unlock, wait. However "worst case" is
that the signalled thread executes, signals, and the first thread was not
waiting at the time so it misses the signal; unlikely but possible. In some
cases it is possible to check the history for missed signals but it seems
programmatically clumsy and does not always fix the problem.

In short... Are monitors actually possible given the resources available? I
was somewhat confused by the lack of atomic unlock/sleep.

-joey

[MichaelAivaliotis]

Well, there are no specific LabVIEW functions to implement a Monitor. However, if you only have a single consumer then you don't really need semaphores. You can try using Queues. Queues can be initialized and coded like Notifiers however they maintain the entire history of the signals in a buffer. As long as your consumer can run in a parallel process (dynamic VI), it will eventualy get through all your messages. So if 3 are sent one after another then the first one will be detected and executed and the other 2 will wait their turn.

When initializing queues, you can specify how big your history can be. If the limit has been reached then no new messages will be sent until there is room in the queue. If you leave this unwired then there is no queu
e limit.

Now if you have multiple monitors (queues) waiting to operate on the same data then after the queue has been received you should use a semphore to lock access to the data being manipulated. This way even if another queue tries to access the data it will have to wait.

Michael Aivaliotis

[Greg_McKaskle2]

....
> In short... Are monitors actually possible given the resources available? I
> was somewhat confused by the lack of atomic unlock/sleep.

In addition to the synchronization functions on the palette, there is another
that people often overlook. If not marked as reentrant, each subVI call is
an atomic operation, a critical section. This means that anytime you need
some combination of actions to be atomic, such as when allocating or destroying
synchronization primitives to avoid deadlocks, you may want to do these things
inside of a subVI so that access is limited to one at a time.

Greg McKaskle

[Joseph Oravec]

"Greg McKaskle" wrote in message
news:3BE5717D.C44CD2AA@austin.rr.com...
> In addition to the synchronization functions on the palette, there is
another
> that people often overlook. If not marked as reentrant, each subVI call
is
> an atomic operation, a critical section. This means that anytime you need
> some combination of actions to be atomic, such as when allocating or
destroying
> synchronization primitives to avoid deadlocks, you may want to do these
things
> inside of a subVI so that access is limited to one at a time.

Excellent!!! This is the info I found relatively poorly documented, but then
again I have seen much more procedural than threaded code generated by
labview programmer. So just to cla
rify.....

You are saying that if I do not mark a subVI as re-entrant, I am guaranteed
that the subVI is run atomically. Therefore I can make implement
Mesa-Monitor wait with a subVI which unlocks then waits within a subVI. So
when I do a Wait() within that non-rentrant subVI, labview will switch out
to something else on the ready-queue; preferably some other thread marked
re-entrant.

Thanks! Thats exactly what I needed to know. Theres plenty of information on
data acquisition, but I wish NI would produce (or organize) some more
advanced programming documentation on topics like this.

-joey

[Greg_McKaskle2]

> Excellent!!! This is the info I found relatively poorly documented, but then
> again I have seen much more procedural than threaded code generated by
> labview programmer. So just to clarify.....
>
> You are saying that if I do not mark a subVI as re-entrant, I am guaranteed
> that the subVI is run atomically. Therefore I can make implement
> Mesa-Monitor wait with a subVI which unlocks then waits within a subVI. So
> when I do a Wait() within that non-rentrant subVI, labview will switch out
> to something else on the ready-queue; preferably some other thread marked
> re-entrant.
>

Just to make sure I don't lead you astray, the VIs act as critical sections.
There can only be one call in a non-reentrant subVI at a time.
All other
calls will queue up until the first finishes. I shouldn't have used the
word atomic. It is possible for other VIs to run at the same time. I'm
a little fuzzy as to what it is you are trying to build, but with the
critical section and semaphore you can make any other synchronization
mechanism.

Greg McKaskle