Output to console from DerivedThread class strange

Manu turkeyman at gmail.com
Wed Feb 8 00:47:29 PST 2012


Well I can't speak on behalf of the JVM, but what it does when it enters a
break mode, or how it schedules its threads are completely in its own world.

Multitasking isn't really any different now than it was back then...
Pre-emptive multitasking is simply cooperative multitasking, but with the
added concept of automatic yielding after time slices, and that thread is
so short, it will probably not exceed a single OS timeslice. As soon as it
enters the debugger state, all threads will halt.
I expect exactly what you see personally from the operating system. I have
no experience with Java, but I wouldn't base any opinions about computer
software behaviour on what Java does. It lives in its own universe.

If you spawned those threads, and then entered a loop doing something
fairly busy on the main thread, it will exceed its timeslice within a short
time, and then the other threads would have their turn. Your program is
just too short to predictably visualise the OS threading behaviour.

Run this:

It should 'tick' for a while, and you'll see the other threads slip in
within a short time as they get given time by the scheduler.

 int main(string[] argv)
{
   DerivedThread dt1 = new DerivedThread();
   dt1.start();

   DerivedThread dt2 = new DerivedThread();
   dt2.start();

   DerivedThread dt3 = new DerivedThread();
   dt3.start();

   for(int i=0; i<1000000; ++i)
      writeln("tick");

   Thread.sleep(dur!("seconds")( 4 ));
   return 0;
}

On 8 February 2012 08:56, Oliver Puerto <saxo123 at gmx.de> wrote:

> Hi Manu,
>
> thanks for taking some time to answer. I just wrote a little Java program
> that does just the same:
>
> public static void main(String[] args)
> {
>    Thread thread1 = new Thread(new HelloWorldThread());
>    thread1.start();
>
>    Thread thread2 = new Thread(new HelloWorldThread());
>    thread2.start();
>
>    Thread thread3 = new Thread(new HelloWorldThread());
>    thread3.start();
>
>    System.out.println("done");
> }
>
> "Hello world" is printed to the console as soon as I jump in the Java
> eclipse debugger over any thread?.start(). I have a breakpoint on the last
> sysout("done") line to prevent the program to terminate before I'm done
> with seeing things in the debugger. So there is no single Thread.sleep here
> and no yielding. This is the behavior I would expect from my D program as
> well.
>
> This somehow reminds me of older versions of VisualWorks Smalltalk where
> multi-threading was not preemptive, but cooperative: threads with same
> priority do not interrupt each other but run till completion unless one of
> the threads does a Processor.yield.
>
> When your programm was irresponsible in a certain situation you added some
> more Processor.yield to the code and things were better. But at the same
> time the additional yields caused some more incorrectly synchronized access
> to shared data to cause race conditions. Without people that do not
> understand concurrency well this was not easy ...
>
> I still don't understand why my D program behaves as described in my
> initial post and not like the corresponding Java program. Is this really
> the debugger?
>
> Cheers, Oliver
>
> -------- Original-Nachricht --------
> > Datum: Wed, 8 Feb 2012 01:01:22 +0200
> > Von: Manu <turkeyman at gmail.com>
> > An: "digitalmars.D" <digitalmars-d at puremagic.com>
> > Betreff: Re: Output to console from DerivedThread class strange
>
> > I'm not sure why you are asking me about this?
> >
> > The problem I think is with your understanding of the debugger, and sleep
> > states of other threads.
> > If you break on a breakpoint to step the program, all threads be stopped.
> > If you step the code one line at a time in the debugger, it will not
> yield
> > to the other threads while stepping, the new thread will not begin until
> > the current thread has a reason to yield, and you won't see anything.
> > When you step over the sleep, the program will execute the sleep, which
> > will then cause a wait for some moments, immediately handing the
> execution
> > to another thread for that time, and during this time the other thread
> > will
> > have opportunity to print their message and exit. Sleep will always yield
> > the current thread immediately, even if you sleep for 0.
> > With the sleep calls commented out like that, the main thread will not
> > reach a point where it will be forced to yield to another thread, so you
> > won't see it until the end.
> >
> > What I expect to happen, without breaking to the debugger, with all
> sleeps
> > commented out; the 3 prints will happen after the program exits (it will
> > take some time before the main thread yields to the new created threads)
> > ..
> > if you uncomment any of those sleeps, all prints coming before it will
> > print at that time...
> >
> > On 8 February 2012 00:28, Oliver Puerto <saxo123 at gmx.de> wrote:
> >
> > > Hello,
> > >
> > > I have a question concerning threading. I use Visual Studio with the
> > > Visual-D plugin. The problem is somehow that when executing the code
> > below
> > > "Derived thread running." is displayed 3 times on the console but not
> > > before "return 0" is reached. Then "Derived thread running." is
> > displayed
> > > 3x all of a sudden, but not each one by one after each other. This
> looks
> > a
> > > bit strange to me.
> > >
> > > When I unquote the Thread.sleeps after every d?.start() "Derived thread
> > > running." is displayed immediately on the console when stepping over
> > > Thread.sleep with the debugger. When stepping over d*.start() still
> > nothing
> > > happens regardless how much time I wait in the debugger till I jump to
> > the
> > > next line. I can't make really head or tail of this. I would expect
> > > "Derived thread running." to appear on the console somewhen after
> > > d?.start() was executed. Thereafter I could do an additional
> > Thread.sleep
> > > if I wanted to. But this would not be necessary for any "Derived thread
> > > running." message to be displayed on the console.
> > >
> > > I believe there is something with the debugger I don't understand or
> > don't
> > > realize. Any suggestions/ideas?
> > >
> > > Thank you, Oliver Plow
> > >
> > >
> > > import std.stdio, core.thread;
> > >
> > > import DerivedThread;
> > >
> > > int main(string[] argv)
> > > {
> > >    DerivedThread dt1 = new DerivedThread();
> > >    dt1.start();
> > >    // Thread.sleep(dur!("seconds")( 1 ));
> > >
> > >    DerivedThread dt2 = new DerivedThread();
> > >    dt2.start();
> > >    // Thread.sleep(dur!("seconds")( 1 ));
> > >
> > >    DerivedThread dt3 = new DerivedThread();
> > >    dt3.start();
> > >    // Thread.sleep(dur!("seconds")( 1 ));
> > >
> > >    Thread.sleep(dur!("seconds")( 4 ));
> > >    return 0;
> > > }
> > >
> > > ------------------ DerivedThread.d ------------------
> > >
> > > import std.stdio, core.thread;
> > >
> > > class DerivedThread : Thread {
> > >        this() {
> > >                super( &run );
> > >        }
> > >
> > > private :
> > >        void run() {
> > >                writeln("Derived thread running.");
> > >        }
> > > }
> > > --
> > > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> > > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> > >
>
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120208/e86ed6e2/attachment-0001.html>


More information about the Digitalmars-d mailing list