Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How heavy is it to run a background process ?  RSS feed

 
Kaustubh Patil
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How heavy is it if I continiously keep a background process running ?
For example say that i have a process that continiously keeps on checking a vector to see if the elements have a perticular data.
Is it efficient to check it in the background process or in the main pocess at some point of time.
Kaustubh.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you say a background "process", I assume you mean a background "thread". Running a Java process is really expensive, in terms of memory, though much less so in terms of CPU. Reducing this cost was the reason that threads were introduced into operating systems.
The cost of having an extra thread depends on whether you have native threads (in which case it's platform-dependent) or "green" threads. But it's not particularly high. Many good Java programs happily have tens (but probably not hundreds) of threads.
The particular reason that you suggest for your background thread sounds like "polling". That is, you propose to periodically check an object to see if it has changed.
Polling is something that you should try to avoid. Use wait()/notifyAll() instead. For instance, if you want your background thread to react to changes in a Vector, you can have the background thread wait() on the Vector object. Then, whenever you change the Vector object, do a notifyAll() (or even create a subclass that does this automatically).
When a thread is in wait(), its cost is minimal. This compares to polling where the thread has to be woken up periodically. Also, wait() can react pretty quickly (depending on load and priority) to a notifyAll(), whereas polling has a built-in latency.
To make a background thread more "background", you can give it a low priority. This means that other threads contending for CPU will run first. However, beware of deadlock or long delays caused by a low-priority thread getting a lock (your access to the Vector will need to be synchronised) then pausing for ages, retaining the lock, preventing other threads from getting it.
 
Kaustubh Patil
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thankx Peter for the reply..
The perticular situation where i am using the background thread is in the Connection Pooling.
My class of connection pool has a vector as collection of connections. The background thread continiously keeps on checking wheather the connections are alive or not and if they are not then removes them from the collection.
I can implement it in 2 ways ,
one as i have written using a background process and the other is to check at the time when the connection is requested (in this case there won't be any multithreading involved)
which one is better ?
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You don't say what type of connections are involved. JDBC? URL? Socket? ...
The advantage of cleaning up dead connections in your pool when a new connection is requested is simplicity. You rightly identify that this won't be multi-threaded, so it's much easier to get right. It is also less resource-intensive.
However, you build in a delay into the aquisition of a connection, because dead connections have to be cleaned-up before a connection can be reused or allocated for the requester.
By using another thread, the work of cleaning up dead connections is done in the background, perhaps as a low-priority task that only runs when nothing else wants the CPU (care of deadlocks!). It's a bit more expensive, overall, especially if you use polling, but may be worth the cost.
Which method you choose is application-specific, I think. It depends whether you want low total cost with delayed connection allocation or higher total cost but speedier connection allocation.
Here's another thought, which may or may not suit your application ...
Perhaps your application either does or could arrange to release all references to "dead" connections. That would mean that the reference in your Vector of connections would be the only one stopping the connection gettting gc'd.
If this is the case, you could put WeakReferences to connections in your Vector, instead of direct references. You could register all these WeakReferences with a ReferenceQueue. Whenever a connection was about to get gc'd, because only a WeakReference to it was left, your ReferenceQueue would get told.
A background thread could then have a loop doing ReferenceQueue.remove(). Each time it got a WeakReference from the queue, it could remove the associated entry from the Vector.
Using ReferenceQueue.remove() has similar advantages to using Object.wait(). That is, the cost is minimal while waiting, because it's a notification scheme, not a polling scheme. However, with ReferenceQueue.remove(), you don't need to do a Object.notify() yourself; the garbage collector does it for you.
Just a thought.
P.
 
Kaustubh Patil
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The kind of connection i am using is JDBC..
And i am checking the connection in a little different way..
Say a request for connection has come..I remove a conn. from the collection ..Then i check wheather it is alive..if yes then i return it and the method exits..else i recursively try for another conn. from the collection...and the whole process continues untill a live connection is found..
In this way its ensured that the connection returned is alive and every time its not required to search the whole collection for the dead connections..
And forgive my ignorance but i would like to know more about the weak-references that u mentioned..what r they ? r they references to the references.. ? pl. tell me..
Kaustubh
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!