barbershop model

[hariharan.priya]

Hi,

I am a beginner in programming! I work part time on C++ projects in
University. Currently, i am developing a barber shop simulation model.

The current model is--> Each time when the client arrives, he checks
for a free barber. if a barber is free, he is serviced. Else he waits
in a queue (Common queue for all clients).

After barber is done with his work, he checks if the queue is empty, if
not, the 1st client in the queue is served by the barber.

Now i need to change it as follows--> The client has a preference for
barber ( i am done with this)! and each barber has HIS SEPARATE queue!
the client checks if this barber is free! if not he waits in the
corresponding queue of the barber! I wish to know how to implement this
qeueue for each barber. I am just pasting the source code of barber,
where i have generated the number of barbers and has set his chair
number, and also the intialisation of the clientqueue.


queue<client*> barber::clientQueue; // this is a common queue

barber::barber( int numberOfBarbers ) : currentClient( 0 ), name( 0 ) {
for( int i = 1; i <= numberOfBarbers; i++ ) {
barber* b = dynamic_cast<barber*>( this->clone( ) );
b->setChairNumber( i );
barbers.push_back( b );
b->name = new char[255];
sprintf( b->name, "%s - %i", this->getClassName( ), i );
}
}

 

[osmium]

I am a beginner in programming! I work part time on C++ projects in
University. Currently, i am developing a barber shop simulation model.

The current model is--> Each time when the client arrives, he checks
for a free barber. if a barber is free, he is serviced. Else he waits
in a queue (Common queue for all clients).

After barber is done with his work, he checks if the queue is empty, if
not, the 1st client in the queue is served by the barber.

Now i need to change it as follows--> The client has a preference for
barber ( i am done with this)! and each barber has HIS SEPARATE queue!
the client checks if this barber is free! if not he waits in the
corresponding queue of the barber! I wish to know how to implement this
qeueue for each barber. I am just pasting the source code of barber,
where i have generated the number of barbers and has set his chair
number, and also the intialisation of the clientqueue.

<snip>

I guess I would make a queue for each barber and also a common queue. Each
client gets a time stamp when he enters the system, no ties permitted. When
a barber becomes free he checks the time stamp of the leading contender in
his private queue with the time stamp of the leading contender in the common
queue. He takes whoever has the oldest time stamp.

 

[hariharan.priya]

Well, thank you! do u have any idea on how to declare the queue for
each barber? syntax?

 

[osmium]

Well, thank you! do u have any idea on how to declare the queue for
each barber? syntax?

Something like this for a first cut. It compiles.

#include <iostream>
#include <deque>
#include <vector>

// in a real program, this would be in a header file
struct Client
{
int id;
double time_stamp;
};
//----------------
typedef std::deque<Client> QT; // queue type
// end header

using namespace std;

int main()
{
vector<QT> vq; // index 0 - collective queue,
// else one for each barber

// stuff
}

 

[Earl Purple]

Something like this for a first cut. It compiles.

#include <iostream>
#include <deque>
#include <vector>

// in a real program, this would be in a header file
struct Client
{
int id;
double time_stamp;
};
//----------------
typedef std::deque<Client> QT; // queue type

You could use double or a counter for the time stamp, and then you
would have one queue for each barber and one generic queue. At the time
when a barber becomes available, you must compare the timestamps in
each queue, i.e. the one for the generic queue and the one for the
barber-specific queue.

 

[Geo]

<snip>

I guess I would make a queue for each barber and also a common queue. Each
client gets a time stamp when he enters the system, no ties permitted. When
a barber becomes free he checks the time stamp of the leading contender in
his private queue with the time stamp of the leading contender in the common
queue. He takes whoever has the oldest time stamp.

You don't need to mess around with time stamps.

You have a queue for each barber and a common queue. When a barber
needs a customer he checks his queue, if empty then the common queue.
When a customer arrives he always joins the common queue. When he gets
to the front of the common queue, if the first free barber is not the
one he wants, he goes to the end of that barbers queue. Done.

 

[Earl Purple]

You don't need to mess around with time stamps.

You have a queue for each barber and a common queue. When a barber
needs a customer he checks his queue, if empty then the common queue.
When a customer arrives he always joins the common queue. When he gets
to the front of the common queue, if the first free barber is not the
one he wants, he goes to the end of that barbers queue. Done.

Seems a good solution. In the implementation:

- You would signal the common queue when a barber is available (which
means nobody in his own personal queue too).

- If after signalling, the customer at the front did not go to the free
barber but joined a different queue, you must signal again.

 

[JustBoo]

Seems a good solution. In the implementation:

- You would signal the common queue when a barber is available (which
means nobody in his own personal queue too).

- If after signalling, the customer at the front did not go to the free
barber but joined a different queue, you must signal again.

Sorry if I'm not much help here, but I remember having a similar
problem a long, long time ago. An old crusty engineer dug up some
really old literature about Railroad Yard Scheduling. Apparently back
when railroads were huge, this was a big engineering problem. Getting
all those trains queued up correctly at the right time on the various
tracks was a real science.

For clarity: Here is a link that shows a picture of a railroad yard.
Though the article is not about them.
http://en.wikipedia.org/wiki/Classification_yard

 

[osmium]

You don't need to mess around with time stamps.

Any simulator worth it's salt already *has* a time stamp on when the client
entered the system. You don't write simulators simply to burn up excess CPU
cycles. One of the products of the simulator has to the time spent waiting,
presented in various forms. Mean, worst case, as a histogram of all
clients. So nothing is accomplished by getting rid of the time stamp. I
don't object to a revised method, but don't implicitly attribute
non-existent benefits to the change.

 

[osmium]

Any simulator worth it's salt already *has* a time stamp on when the
client entered the system. You don't write simulators simply to burn up
excess CPU cycles. One of the products of the simulator has to the time
spent waiting, presented in various forms. Mean, worst case, as a
histogram of all clients. So nothing is accomplished by getting rid of the
time stamp. I don't object to a revised method, but don't implicitly
attribute non-existent benefits to the change.

A point I forgot to make. I think it is far better to fully parameterize
objects as they enter the system, If you do it in bits and pieces here and
there it gets terribly confusing. So some of the proposed changes (I didn't
try to fully absorb what all was proposed) will require a new field to tell
whether the client is a wait kind of guy - and has favorite barber and that
barber's id - or he takes pot luck. The way I had it that information was
used and discarded when he joined a queue.

 

[JustBoo]

For clarity: Here is a link that shows a picture of a railroad yard.
Though the article is not about them.
http://en.wikipedia.org/wiki/Classification_yard

I was wrong. The article is about train yards. Even better.

 

[Geo]

Any simulator worth it's salt already *has* a time stamp on when the client
entered the system. You don't write simulators simply to burn up excess CPU
cycles. One of the products of the simulator has to the time spent waiting,
presented in various forms. Mean, worst case, as a histogram of all
clients. So nothing is accomplished by getting rid of the time stamp. I
don't object to a revised method, but don't implicitly attribute
non-existent benefits to the change.

The OP made no mention of tracking time, but you may well be correct. I
was just highlighting an alternative solution that did not require
tracking time differences. The benefit of not doing time comaprisons is
IMO far from 'non-existant' but the fun in programming is that there is
seldom 'one' solution.