[Boost-users] Multithreaded Signal Library

From: Stephen torri (storri_at_[hidden])
Date: 2005-01-13 19:25:10

Since it has been advise by many people in the past that retrofitting
software is troublesome and expense. I am looking at the issues of
redesigning the signals library from scratch to keep the
same interface. Before providing a new solution to consider I have a few
questions.

Is the relationship of signals to slots 1 to N where N = 0 to some
value? From what I have read I believe this is true.

Since signals are not copyable? N processes desiring to signal the M
slots (N = 0 to some value N, M = 0 to some value M) will have to do it
through the same signal object if the processes are of the same type
(class has an signal object as a variable). Right?

The second question comes from my initial understanding of the signals
library. I was thinking about this scenario: There is a class call Cart
which has a signal boost::signal<void()> in_Parking_Lot in it. Since a
store will have multiple Carts for customers to use the owner has
programmed his carts to signal the front desk computer when they are
moved out of the store.

class Cart {
private:
        boost::signal<void()> in_Parking_Lot;

public:

  void init (FrontDesk& fd) {
        in_Store = true;
        in_Parking_Lot.connect(fd);

  void process () {
          for (;;)
        {	
                Check location (If in store set in_Store = true vice 
                                versa if not).
                
                if ( ! in_Store )
                {
                        in_Parking_Lot();
                }
        }
};

So if I have a very small shop with 50 Carts, all 50 Carts be using the
same signal object to alert the front desk. If I had a big computer with
51 cpus (50 Carts and 1 FrontDesk) to run each process I have a race
condition. Which process gets to alert the front desk when?

>From what I understand the relationship of signals to slots is (1:N)
where N is 0 to some number. So I have to have some structure in place
so that I keep things safe (e.g. no race conditions or starvation) while
maintaining throughput when the 50 processes try to send a signal at the
same tiem.

So given my example I was wondering what are the properties that I need
to maintain? For example should each call to the signal's operator()
function be blocking (each signaling process must update all the slots
listening for the signal before returning) or non-blocking (some other
process handles updating the slots while the signaling process returns
back to work right away).

The final question is that if indeed the relationship of signals to
slots is 1:N then the multi-threading problems begins to surface more
predominately. That is T threads, where T is a Cart object, use 1 signal
to notify N slots. We have a restricted resource, the 1 signal, to
update N slots at various times during the lifetime of the T threads.
Is this the problem of using the signal library with multiple threads?

I will leave things there for now and await your response.

Stephen