Output to console from DerivedThread class strange
Manu
turkeyman at gmail.com
Wed Feb 8 04:02:34 PST 2012
On 8 February 2012 12:13, Oliver Puerto <saxo123 at gmx.de> wrote:
> Hi Manu,
>
> I also played around with inserted writelns. I now picked up your approach
> doing this here:
>
> for(int i=0; i<1000000; ++i)
> writeln("tick");
>
>
> Actually, 5 iterations were enough and all three "Derived thread running"
> messages appeared on the console. After running the program form the
> console several times there was also a run where the output was also
> different from the previous ones (order of "tick" and "Derived thread
> running" on the console.
>
> In Java I start the same program 3 times and every time the order of the
> output on the console is different. This can be repeated as much as I want
> and for almost every single run the output appears to be different from
> previous runs.
>
> The D program also produces different output, but the number of runs till
> output is different is higher. Maybe something like a factor 3. Anyway, I
> don't want to appear annoying or picky. I only want to understand what's
> happening. Maybe there is a way to change number of ticks for a time slice
> in D.
>
No, this is the operating systems scheduler you are seeing, they could
change it at any time, with any update to the OS. You have to accept this
it how it works. This is what threading is :)
2 simultaneous threads are not actually synchronised, there are no
guarantees about execution timings... that's the whole point actually. If
you want to synchronise your threads in an intricate way, you need to use
thread synchronisation functions, which are always supplied in any
operating system, but this is a huge field of study in its self.
> Anyway, since the output of the D program is different in order when you
> run the program several times my concerns are resolved. That's good as the
> last days I started to like D more and more and would really like to
> continue with it :-).
>
Remember, this has nothing to do with D at all. There is nothing D can do
to influence this behaviour. You are seeing the operator system scheduling
threads however it likes.
Java runs inside a VM, and so it has its own control over its threads, but
even that at some level will fall back to the OS scheduler too.
> My little actor solution was really easy to create. It was almost as quick
> as if I had coded the same thing quickly in Java. Incredible, how
> productive D is and how fast the build times are taking into account that
> it is meant for system programming. Has anybody realized how similar D and
> Scala are in their core ideas? And build times in D are really better than
> in Scala ... Amazing, and creation of D obviously started before Scala.
>
I have found D to be at least as productive, but for me, usually much MORE
productive than Java. Java is simple and structured, but D allows you to do
all the stuff from C/C++, that Java can't really do, and required really
big bloated Java code to express. I see D as something of the best of both
worlds personally...
>
> Regards, Oliver
>
> P.S.: Something else ... I googled the names of some of the people that
> posted to this mailing list and did not find these posts in Google. I want
> to limit what can be found in Google when making a search for my name.
> That's why I don't supply my real name. In the past simply ways too much I
> had posted in the Internet popped up in Google in the end somehow. Is this
> mailing list somehow "Google-safe"? Then I won't mind supplying my real
> name like everbody else ...
>
This isn't a public mailing list, you have to subscribe to access it, so
google cant index it. Their crawl-bot doesn't create accounts or try and
subscribe to websites to index private pages... and even if it did index
it, nobody without an account could look at it themselves.
> -------- Original-Nachricht --------
> > Datum: Wed, 8 Feb 2012 10:47:29 +0200
> > Von: Manu <turkeyman at gmail.com>
> > An: "digitalmars.D" <digitalmars-d at puremagic.com>
> > Betreff: Re: Output to console from DerivedThread class strange
>
> > 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
> > >
>
> --
> 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/8967a026/attachment-0001.html>
More information about the Digitalmars-d
mailing list