Concurrency newbie

[=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=]

Hello.

I am working on an assignment for the Parallel Programming course I've
been taking. Among other things, it involves a server which should
accept only 4 client connections. After the fourth connection has been
established, I would like the server to stop listening for connections.
Only when one of the connections is broken should the server resume its
listening activity.

Now the question is how can I properly set things up so that the server
won't be busy-waiting? I thought of an approach using wait/notify but,
since I am still learning concurrent programming, I am afraid I might be
abusing the concepts.

while (true)
{
while (connections < 4)
{
client = server.accept();
// create client handling object
connections++;
}
wait(); // once there are 4 connections already, stand by until
// a notify()cation is issued
}

Does the code above have any chance of succeeding? Will a notify() call
from a different thread actually wake up the server? What does that
wait() call actually means? From what I've read, it means the server
would be giving up its monitor and allowing any other thread who might
be trying to get hold of that monitor to proceed. Looking at it that way
makes me fear my solution will lead to a dead server, since the server
code is not shared, i.e. there are no other threads wanting to get hold
of that monitor.

My post shows I am definitely confused about these concepts. What I am
basically trying to do is have the server wait on a given condition
(number of connections went down from 4) in order to resume working.
What's the proper way to go about it?

Thank you,

 

[Robert Klemme]

Hello.

I am working on an assignment for the Parallel Programming course I've
been taking. Among other things, it involves a server which should
accept only 4 client connections. After the fourth connection has been
established, I would like the server to stop listening for connections.
Only when one of the connections is broken should the server resume its
listening activity.

Now the question is how can I properly set things up so that the server
won't be busy-waiting? I thought of an approach using wait/notify but,
since I am still learning concurrent programming, I am afraid I might be
abusing the concepts.

while (true)
{
while (connections < 4)
{
client = server.accept();
// create client handling object
connections++;
}
wait(); // once there are 4 connections already, stand by until
// a notify()cation is issued
}

Does the code above have any chance of succeeding? Will a notify() call
from a different thread actually wake up the server? What does that
wait() call actually means? From what I've read, it means the server
would be giving up its monitor and allowing any other thread who might
be trying to get hold of that monitor to proceed. Looking at it that way
makes me fear my solution will lead to a dead server, since the server
code is not shared, i.e. there are no other threads wanting to get hold
of that monitor.

My post shows I am definitely confused about these concepts. What I am
basically trying to do is have the server wait on a given condition
(number of connections went down from 4) in order to resume working.
What's the proper way to go about it?

If my memory doesn't fail me this is a typical application case for a
semaphore.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Semaphore.html

There might also be a socket based solution (i.e. a restriction) not sure.

Kind regards

robert

 

[Thomas Hawtin]

I assume you have placed this in a synchronized (this) block (or
synchronized method). Also presumably the client threads finish with
something like:

synchronized (this) { // same this as above
this.notify();
--connections;
}

You may notice a problem in that unless the limit is reached, client
threads fail to exit. They cannot enter the synchronized block until the
server is in wait (which releases the lock).

If my memory doesn't fail me this is a typical application case for a
semaphore.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Semaphore.html

Yup. Which will probably be faster, because there is no need to acquire
a lock in the usual case. Not that it matters in this case.

There might also be a socket based solution (i.e. a restriction) not sure.

The operating system will probably set a limit on the total number of
connections.

Tom Hawtin

 

[Remon van Vliet]

Hello.

I am working on an assignment for the Parallel Programming course I've
been taking. Among other things, it involves a server which should accept
only 4 client connections. After the fourth connection has been
established, I would like the server to stop listening for connections.
Only when one of the connections is broken should the server resume its
listening activity.

Now the question is how can I properly set things up so that the server
won't be busy-waiting? I thought of an approach using wait/notify but,
since I am still learning concurrent programming, I am afraid I might be
abusing the concepts.

while (true)
{
while (connections < 4)
{
client = server.accept();
// create client handling object
connections++;
}
wait(); // once there are 4 connections already, stand by until
// a notify()cation is issued
}

Does the code above have any chance of succeeding? Will a notify() call
from a different thread actually wake up the server? What does that wait()
call actually means? From what I've read, it means the server would be
giving up its monitor and allowing any other thread who might be trying to
get hold of that monitor to proceed. Looking at it that way makes me fear
my solution will lead to a dead server, since the server code is not
shared, i.e. there are no other threads wanting to get hold of that
monitor.

My post shows I am definitely confused about these concepts. What I am
basically trying to do is have the server wait on a given condition
(number of connections went down from 4) in order to resume working.
What's the proper way to go about it?

Thank you,

First of all, what wait() does is make the current thread wait until ther
notify or notifyAll method is called for that same thread. So as long as you
notify it again at some point it is a valid (although questionable way) to
make your program only allow 4 connections. Secondly your code snippet is
incorrect for what you want, try :

-> entry point for your program
while(!shutdownRequested) {

Socket socket = serverSocket.accept();

if(activeClientCount < 4)
initMyBrandNewSocket(socket);
else
rejectSocket(socket);
}
-> exit point

public void rejectSocket(Socket s) {

writeMessage(s, "Sorry, server is full baby!");

s.close();
}

Like you can see above, how i'd personally do this is keep the server accept
loop active, always accept connections (even if connectionCount > 4). Then
send a "server reached maximum capacity" kind of message to clients that
cause your server to pass the 4 client mark, then close the socket of the
"illegal" client and wait for the next accept. This is a better and neater
approach to your problem.

Remon van Vliet

 

[=?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?=]

Thomas Hawtin wrote:

[...]

You may notice a problem in that unless the limit is reached, client
threads fail to exit. They cannot enter the synchronized block until the
server is in wait (which releases the lock).

Thank you for your post. I was just struggling with the very thing you
describe here. I had prepared a synchronized method named
clientConnectionTerminated() to handle the updating of the connection
count and to notify the server that it could again listen for incoming
connection requests. That method would be called by a connection handler
object when the connection would be terminated by the client.

The problem, as you have explained, is that in the case where the
maximum number of connections had not yet been reached, the connection
handler would block on the call to the clientConnectionTerminated()
method, as the Server would not yet have given up the lock on its
monitor. Have I got it right?

Yup. Which will probably be faster, because there is no need to acquire
a lock in the usual case. Not that it matters in this case.

I guess this was a typical situation of choosing the wrong tool for the
job. I will indeed consider using semaphores. Just a quick question: I
had someone tell me that they were not actually part of the standard
library, but some kind of non-official add-on facility. Is that still
(if it's ever been) true? May I safely use it in my projects without
compromising portability and compatibility?

Thank you,