This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: java.util.TimerTask


> public class x
> {
> 
>   public static void main (String s[])
>   {
>     
>     Timer mTimer=new Timer();
>     QueueTask mQueueTask=new QueueTask();
>     //and does something
>     mTimer.schedule(mQueueTask,0,100);
>   }
> }
> 
> works correctly AFAICS.

Ok. I'll review if I did something else wrong. It looks as if it is what
I did, but I've probably overlooked something.


> What platform is this?  Windows uses WaitForMultipleObjects(), posix
> uses pthread_cond_timedwait().  Neither should eat CPU.

I'm developing on linux. (I'd like to test on win32 too, however):

$ gcj -v
Reading specs from
/usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs Reading specs
from
/usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/../../../libgcj.sp
ec rename spec lib to liborig
Configured with: ../gcc-3.3/configure --prefix=/usr/local/gcc/3.3
--enable-languages=c,c++,java --enable-threads=posix Thread model: posix
gcc version 3.3


By the way, I've found a way in which "waiting" doesn't consume CPU:

		try
		{
			Thread thisThread = Thread.currentThread();
			while (true)
			{
				thisThread.sleep(10000);
			}
		}
		catch(Exception e) {}


In order to verify, I've looked up in libjava sources if
java.lang.Object.wait(long) and java.lang.Thread.sleep(long) are
implemented in a substantially different way:

natObject.cc, line 219:
switch (_Jv_CondWait (&si->condition,&si->mutex, timeout, nanos))

natThread.cc, line 178 and following:
  natThread *nt = (natThread *) current->data;
  _Jv_MutexLock (&nt->join_mutex);
  _Jv_CondWait (&nt->join_cond, &nt->join_mutex, millis, nanos);
  _Jv_MutexUnlock (&nt->join_mutex);

The only apparent difference between natObject's and natThread's
implementations seem to be that natThread wraps its goodies in a mutex?
I wouldn't like to jumpt to conclusions, but could it be that wrapping
with a mutex prevents CPU consumption anyhow? Could someone who
deeply understands this, pitch in?

Another question, if someone knows something about the subject. I'm
currently using a TimerTask to poll the filesystem. I'd rather,however,
(if possible) plug in to some kind of filesystem notification system...
Linux-only would do. I'm perfectly willing to native wrap stuff into
CNI and delegate this to native methods. Any thoughts?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]