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,

-- 
Ney Andr� de Mello Zunino
Graduando em Ci�ncia da Computa��o
Universidade Federal de Santa Catarina

Ney Andr� de Mello Zunino wrote:
> 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

Robert Klemme wrote:
> Ney Andr� de Mello Zunino wrote:
>>
>>   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
>>   }

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
-- 
Unemployed English Java programmer
http://jroller.com/page/tackline/

"Ney Andr� de Mello Zunino" <zunino@inf.ufsc.br> wrote in message 
news:e0gojm$7m5$1@emma.aioe.org...
> 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,
>
> -- 
> Ney Andr� de Mello Zunino
> Graduando em Ci�ncia da Computa��o
> Universidade Federal de Santa Catarina

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 

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?

>> 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.

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,

-- 
Ney Andr� de Mello Zunino
Graduando em Ci�ncia da Computa��o
Universidade Federal de Santa Catarina