Master/Slave vs Producer/Consumer templates...?

[Daklu]

So tonight I gave a presentation on QSMs at the local LUG and it got me thinking about the differences between a "slave" and a "consumer." Thinking I'd get some information by going to the source, I opened the Master/Slave and Producer/Consumer templates included with Labview.

I've never taken the classes that cover these patterns, so I have no idea how NI intends for them to be used. But looking at these two block diagrams I see one pattern implemented using two different transport mechanisms. Aside from the transport, how exactly are these patterns different? The slave help text (copied to the bd) implies a functional difference I don't see. What am I missing?

[todd]

Apparently, it's okay for a Slave to miss a Master's command (slow Slave, quick Master) - but not for a Consumer to miss a Producer's.

[ShaunR]

Producer/consumer is 1-1 master slave is 1-many. Also a producer/consumer is loss-less, master,/slave isn't.

Edited October 19, 2011 by ShaunR

[jgcode]

Yer what they said - one buffers messages (PC) the other only cares about the latest message (MS).

[mje]

(Sorry guys, had a post where I confused the master-slave pattern with another pattern. Redacted.)

[Ryan Podsim]

My understanding is, in the Master/Slave the Slave only cares about the most recent command the Master sends, hence it can miss commands. Where as, with the Producer/Consumer the Consumer CANNOT miss commands and and therefor must be buffered. The P/C also assumes that Consumer can process commands Faster then the producer can create them. If the reverse is true than the problem of the infinite buffer becomes an issue, as your would eventually run out of memory.

In my opinion the M/S works best for UI type implementations and the P/C works best for DAQ type implementations. Personally I don't use the M/S.

[drjdpowell]

My understanding of "Master/Slave" is from electronic hardware, where often groups of identical or similar units are "slaved" together, with one being designated the "master" and all "slaves" being controlled through it. For example, 10 power supplies might be slaved together such that adjusting the voltage of the master adjusts the voltages of all of them.

Generalizing the pattern, I'd say the key feature is that the "master" fully controls the "slaves", control of the slaves is only through control of the master, and a slave only has one master. Both NI examples seem like they could fall into that classification of "master/slave". If one were to modify the Producer/Consumer example to have multiple Producers (which one can do because of the communication buffering) then it would no longer be master/slave.

Another aspect is how you look at the relationship; is the Producer loop exerting control of the Consumer (sending "commands") or is it providing a service ("data")? Master/Slave is about control.

-- James

[Ryan Podsim]

Actually the P/C pattern, since it uses a queue for communications. doesn't really support multiple control any more then a Notifier would. In both you still have the multiple to single implementation, but with a Queue (hence a P/C) you are restricted to a single consumer, where a M/S is not (through the use of the notifier being * to many). So I suppose the main difference between the two are the M/S can support multiple Slaves but the P/C can support multiple producers.

An example for a P/C would writing to a File. You might have multiple locations in your program that want to right information to a file (IE a log file) so a P/C style implementation would be appropriate. But for a test you might have multiple inputs (IE User interface, DAQ, power, ...) that could interfere with the running of the test, in which case you might want to use a M/S style implementation. Its not uncommon for a single program to use both methods. If fact I use and combination of two on a regular basis.

Edited October 19, 2011 by Ryan Podsim

[Jon Kokott]

Does anyone actually use the master/slave? I find it to be useless. Actually I think notifiers in general are pretty useless, every time I've used them I've been "trying" to use them, and ultimately just find them to be less useful than other patterns.

~Jon

[drjdpowell]

Does anyone actually use the master/slave? I find it to be useless. Actually I think notifiers in general are pretty useless, every time I've used them I've been "trying" to use them, and ultimately just find them to be less useful than other patterns.

I wouldn't use the "master/slave" pattern provided, but I do use an alternate structure where a slave loop performs an action continuously, with control parameters provided in a Notifier. The difference being, the loop relies on the "Get Notifier Status" function rather than "Wait on Notification". Admittedly, I could probably do the same thing with a one-element lossy queue.

-- James

[Jon Kokott]

If anyone has ever used the master/slave pattern (and gotten paid for it) where did you use it? It seems like its strictly academic. I wanna see a master slave pattern that uses more than one slave. If you have a master slave with only one slave, it can be drop in replaced with an SEQ using lossy enquue (and probably be better since you can choose to dequeue or preview instead of wait on notification and clear.)

~Jon

[mje]

The master/slave pattern is useful for rendering behaviors. Put a non negative timeout on the wait primitive and let it spin independently. All it cares about is the last supplied value, and if it misses values between frames, it doesn't matter.

[Jon Kokott]

OK, where did you do that? Everyone can show an example of where you "would" use it. But then we all have a more complex system and elect not to use it. Every time I've used this model i've been able to do it with an SEQ.

[Daklu]

Apparently, it's okay for a Slave to miss a Master's command (slow Slave, quick Master) - but not for a Consumer to miss a Producer's.

Also a producer/consumer is loss-less, master,/slave isn't.

Yer what they said - one buffers messages (PC) the other only cares about the latest message (MS).

Those are all just characteristics of the different transport mechanism. My (poorly made) point was that the transport mechanism alone isn't enough (imo) to justify a different pattern name.

Generalizing the pattern, I'd say the key feature is that the "master" fully controls the "slaves", control of the slaves is only through control of the master, and a slave only has one master. Both NI examples seem like they could fall into that classification of "master/slave".

This is much more in line with my perception of what it means to be a "slave," and as you pointed out, they both fall into that category.

If one were to modify the Producer/Consumer example to have multiple Producers (which one can do because of the communication buffering) then it would no longer be master/slave.

Producer/consumer is 1-1 master slave is 1-many.

Ahh, these are the key points I was missing. The intent of the Master/Slave is to produce more slave loops while the intent of the Producer/Consumer is to create more producer loops. Rereading the context help I see they do mention using multiple slave loops in the M/S documentation. (I trust they cover these in the class that teaches these patterns, because the included documentation doesn't make it very clear.) The other thing that struck me as odd was wiring the dequeue/wait error terminals into the case structure. That seemed rather restrictive as it only allows for a go/no go command. I assume the intent is something along the lines of this:

I'll add that I don't think the "Producer/Consumer" name is the best way to describe that pattern. I view producer and consumer as roles each loop plays at different times. Any loop sending information to another loop is a producer and the receiving loop is the consumer. In the code above the loops just happen to never change roles. To be honest I'm not sure what to call it. It's more of a statically defined publish/subscribe.

[jgcode]

To be honest I'm not sure what to call it. It's more of a statically defined publish/subscribe.

IMHO I would stick with the NI nomenclature as it would avoid confusion when discussing these patterns as that is what they have been referred to in the LabVIEW Community for ages.

[Daklu]

If anyone has ever used the master/slave pattern (and gotten paid for it) where did you use it? It seems like its strictly academic. I wanna see a master slave pattern that uses more than one slave.

I use master/slave all the time. Granted I don't use them with notifiers, but I consider them slaves because all their messages come from a single source, their master. In this example the Mediator loop is the master and the StgCtl and Joystick loops are slaves.

[Daklu]

IMHO I would stick with the NI nomenclature as it would avoid confusion when discussing these patterns as that is what they have been referred to in the LabVIEW Community for ages.

Fair concern. My intent isn't to create more confusion, it's to create more clarity. When somebody says they're using producer/consumer, all that tells me is some sort of information is going from the producer loop to the consumer loop. Anything beyond that is a guess unless I see their code.

So what are the critical characteristics of a producer/consumer pattern in your opinion? Is it multiple senders to a single loop? The template has only a single producer and a single consumer, yet it is producer/consumer. Does it require that information always flow in a single direction, from the dedicated producer loop to the dedicated consumer loop? That's how the template shows it, but one way communication seems to me to limit its usefulness. If the consumer is sending information back to a producer, is it no longer producer/consumer? If not, what is it?

[Jon Kokott]

I use master/slave all the time. Granted I don't use them with notifiers, but I consider them slaves because all their messages come from a single source, their master. In this example the Mediator loop is the master and the StgCtl and Joystick loops are slaves.

The only thing in common with NI's master/slave architecture and your example is that you both call it a master slave architecture. You use unlimited sized queues for messaging => Losslesss messaging, NI's template offers lossy messaging.

I think your code is similar to what a programmer might do to solve a problem, whereas NI's template is a solution searching for a problem.

~Jon

[Tim_S]

... is a solution searching for a problem.

I'm going to have to remember this phrase.

Tim

[Daklu]

The only thing in common with NI's master/slave architecture and your example is that you both call it a master slave architecture.

It's not the only thing they have in common. In both of them all messages to a specific slave loop comes from a single place. That, more than anything else, is what defines a slave in my mind.

You use unlimited sized queues for messaging => Losslesss messaging, NI's template offers lossy messaging.

I don't think lossy vs. lossless is one of the defining characteristics of slaves or consumers. I suspect the template uses notifiers simply because they allow easy 1-to-many communication. I use queues instead because most of the time I want lossless master/slave communication.

whereas NI's template is a solution searching for a problem.

Possibly, but I don't believe they would have put it in there unless someone had found it useful. The template is just a starting point. It's obvious there are ways NI intends it to be used, it's just not obvious what they are. Maybe they consider it okay to replace the notifier with queues?

I do agree the M/S template doesn't seem to map very well to code I've encountered in the wild.

[ShaunR]

I do agree the M/S template doesn't seem to map very well to code I've encountered in the wild.

That's because we generally use the event structure to achieve this.

[Jon Kokott]

I don't think lossy vs. lossless is one of the defining characteristics of slaves or consumers. I suspect the template uses notifiers simply because they allow easy 1-to-many communication. I use queues instead because most of the time I want lossless master/slave communication.

We are in disagreement on this. The implications of having a message never be received are far reaching. It would greatly affect the construct of the underlying code.

Notifiers are one to many, queues are not. Notifier slaves will scale, QSMs (or any dequeue) operator, will not scale to other threads. The notifier will "wakeup" all waiters ONLY once, but only with the latest data. You cannot use a queue to do this, and you cannot do it with an event structure (again lossless transmission of messages.) The template is for some special cases where only the most recent data is important, and the older data can be thrown away.

That's because we generally use the event structure to achieve this.

Not the same as the template, event structures are lossless transmission types.

Honestly, I'm starting to think that the NI "master slave" template, isn't even a master slave pattern. Somebody at NI read a CS Article and created this template. Subsequently its been taught in countless Labview Seminars, then seldom used, or worse, used with the assumption that the message transmission is loss-less, which it isn't (probably only "guaranteed" by fictional windows timing).

[ShaunR]

Not the same as the template, event structures are lossless transmission types.

Actually. thinking more (briefly). That is not a requirement of a Master/Slave. It is more an implementation of the example.In the same way that Pub/Sub is a subset of client/server, so is M/S and P/C. The differences are in the way that they realise the client/server relationship.

[Daklu]

The implications of having a message never be received are far reaching. It would greatly affect the construct of the underlying code.

I fully agree with you there, and as developers we need to understand the tradeoffs when deciding on what transport mechanism to use between two loops. I just don't think the specific transport matters because it is rather easy to duplicate one-to-many relationships between loops using queues.

Notifier slaves will scale, QSMs (or any dequeue) operator, will not scale to other threads.

It's a little more work to scale functionality to multiple threads when using queues to transport, but they do scale perfectly well. Just have a unique queue for each slave and send the message to all of them.

The notifier will "wakeup" all waiters ONLY once, but only with the latest data. You cannot use a queue to do this...

Actually you can. Set the queue size to one and use the lossy enqueue function.

The template is for some special cases where only the most recent data is important, and the older data can be thrown away.

And if the notifier is an inherent part of the M/S pattern, it also means all the slaves operate on the same set of messages and on the identical copies of the data which, as you pointed out earlier, turns it into a solution looking for a problem.

Master/Slave, Producer/Consumer, Observer/Observable, Publisher/Subscriber, etc. describe the relationships between parallel processes, not the implementation. The transport mechanism is an implementation detail and entirely incidental to the relationship. No doubt it is a very important detail, but it doesn't affect the overall relationship between the processes.

[Daklu]

It is more an implementation of the example. In the same way that Pub/Sub is a subset of client/server, so is M/S and P/C. The differences are in the way that they realise the client/server relationship.

Would you care to take a stab at enumerating your understanding of those differences?