boost::condiition lock Problem

ipek

Hi,

To sumarize my problem let me take the printer demo example:
If i expand the code:

void
PrinterI::
printString(const string& s, const Ice::Current&)
{
cout << s << endl;
sleep(5);
}

I am able to call several clients within the sleep and all respond parallel (seeing on Hello World)
But if i replace the sleep call with a class instance which uses boost::condition wait lock I'm not able to start several client calls in parallel:

class Call
{
public:
void callme(string);
void done();
private:
boost::mutex my_mutex;
boost::condition my_con;
};

void Call::callme(string s)
{
boost::mutex::scoped_lock lock(my_mutex);
cout << s << endl;
my_con.wait(lock);

}

void Call::done()
{
my_con.notify_all();
}

void
PrinterI::
printString(const string& s, const Ice::Current&)
{
Call *c = new Call();
c->callme(s);
}


The calls are executed in sequence. The second starts until the condition gets notified.
I have to use boost since the code im working on uses it.

Can someone give me a hint for solving this problem, please.

Thanks,
Mesut

marc

I don't know anything about the boost library, but don't you block concurrent access with a boost mutex? Why do you expect operations to be executed in parallel if you mutex-protect them?

In any case, I think it would be best to post this on the boost mailing list or support forum, as we have no experience with the boost library.

bernard

ipek wrote:

void
PrinterI::
printString(const string& s, const Ice::Current&)
{
Call *c = new Call();
c->callme(s);
}

This code does not make sense. Your mutex and condition need to be shared by several threads to do something useful.

Cheers,
Bernard

ipek

Hi,

thanks for fast reply.

It was an extracted part to visualize the problem. The Call class works with the incoming string.

So i think that
Call *c = new Call();
c->callme(s);

should be invoked every time if a client calls printString and the server should handle incoming request in parallel. So it should generate a new instance of Call. All instances whould running seperate and the mutex had nothing to do with each other. Or am I wrong?

Only the Ice server seems to be blocked, all the rest of my multi threaded program just runs as usual. So that can't be a boost problem.

@Bernard:
The threads should not be synchronized. The condition lock waits for an internal signal occurrence and has nothing to do with the sync of the client calls requests.
As I said: its an extracted problem.

The instances of Call should run separate. But only one call is handled and only on instance is generated.

Mesut

marc

I'm afraid there is not much we can do to help. As I wrote above, we don't know boost, and you have already confirmed that Ice calls your code in parallel if you don't add your Call class.