• that other guy (unregistered)

    MainFristThread1

  • King (unregistered)

    Rex is right, threads are hard to understand. Rex is King!

  • (nodebb) in reply to King

    Hey King (Rex), I know threads are hard for you to understand. just let the junior dev handle it, she may teach you a few things. :)

  • dpm (unregistered)

    Quick show of hands: how many experienced DailyWTFers had the word "singleton" pop into their head the instant they saw "threads"?

  • Raj (unregistered) in reply to that other guy

    This discussion thread was predictable

  • randomdude (unregistered)

    I always thought "T-rex" was short for "Tyrannosaurus-Rex"

    turns out it's "Thread King Rex"

  • that other guy (unregistered) in reply to Raj

    Especially when you can only have one at a time.

  • Foo AKA Fooo (unregistered) in reply to Raj

    This discussion thread2 was predictable

  • Foo AKA Fooo (unregistered)

    Seriously, having slightly more threads than cores can be alright in order to use CPU cycles while some threads wait for I/O. Other than that, this is crazy.

    I guess the idea was to avoid race conditions in global/static variables, because each thread gets its own copy this way, but (a) it doesn't seem to be implemented correctly as this bug shows and (b) if there only was a better way to bind data privately to specific instances of code -- unless the king would object ...

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    Epilogue: Alona was fired for questioning Rex's prowess

  • Mr. TA (unregistered)

    I once saw this approach of copying and pasting code 10 times delivered by Sapient. I was worried that it was typical offshore bad code quality but now I'm relieved that this approach is also taken by senior architects.

  • Peter (unregistered)

    I am highly skeptical of this report. There's just no universe in which 20 identical subclasses make sense, no matter how badly you misunderstand threads.

  • Little Bobby Tables (unregistered)

    I've found that if you design your classes with proper encapsulation and canonical use of getters and setters, most of the problems you get with multi-threading never arise in the first place. It's only when you try to mess about and do things manually so as to "optimize" that things start going haywire. And we all know what the three rules of optimization are, don't we, children?

  • (nodebb) in reply to Foo AKA Fooo

    Seriously, having slightly more threads than cores can be alright in order to use CPU cycles while some threads wait for I/O. Other than that, this is crazy.

    It's not necessary even for I/O bound processing. Asynchronous I/O (e.g. Win32 Overlapped or Completion Ports) will manage that just fine. Waiting synchronously for I/O to complete? Why would you want to do that?

  • Rex (unregistered)

    Bugger Off, I'm just making threading easy!

    You fools.

  • (nodebb)

    Threads are free!

  • Axel (unregistered)

    Alternate title suggestion: "Just Use It."

  • LCrawford (unregistered) in reply to Steve_The_Cynic

    | Waiting synchronously for I/O to complete? Why would you want to do that?

    Because it's simpler to develop, document, debug and maintain. If you have only a handful of threads in a typical app, the tied-up resources of an I/O bound thread are not significant.

    In a busy ASP.NET app, it's a different story where async starts to make sense.

  • siciac (unregistered) in reply to Steve_The_Cynic

    Waiting synchronously for I/O to complete? Why would you want to do that?

    Because Java has great support for threads and no coroutines.

  • (nodebb) in reply to siciac

    Because Java has great support for threads and no coroutines.

    So what? You don't need coroutines to do asynchronous I/O.

  • Little Bobby Tables (unregistered)

    "Rex" is of course a nickname, it's short for "he who rex exerything".

  • Simon (unregistered) in reply to Steve_The_Cynic

    No, but Java doesn't really have any good support for async IO, coroutines or otherwise. It has the low-level primitives like NIO, but that's just the building blocks for an event loop... you're reliant on third-party libraries for any kind of usable API to code to. Forget about querying a relational database – JDBC is totally synchronous – unless again, you can dig out some libraries that provide a non-standard async API on top of your specific database. Supposedly there's a new async database API coming out of Oracle, but it's not here yet, and the way the JEE world has gone in recent years, I don't expect to see it in production this decade...

  • Foo AKA Fooo (unregistered) in reply to Steve_The_Cynic

    For largely I/O bound processing, yes. But for typical jobs which are mainly CPU bound, but do some occasional I/O (especially input), it's easier to use this time on other threads, rather than trying to fit some other jobs in. That's why I said "slightly".

  • (nodebb) in reply to Simon

    I don't expect to see it in production this decade...

    Given that this decade ends in less than 17 months, I wouldn't either.

  • (nodebb) in reply to Simon

    Java doesn't really have any good support for async IO

    QFT. I've done async IO in Java and it was both weird and horrible. It's also terribly integrated with the old IO classes and some operations are only available on the old classes and others are only on the new ones… to say nothing of just how limited it all is (e.g., there's no async IO support for inter-process pipes out of the box). Grr…

  • Developer Dude (google) in reply to King

    private String rex = "Brillant";

  • Developer Dude (google) in reply to Peter

    You obviously have never worked for a megacorp. ;-)

    Seriously, I have seen worse. It doesn't make sense, but then it doesn't have to.

    Remember "A fundamental rule in technology says that whatever can be done will be done." - Andy Grove

  • Developer Dude (google) in reply to Simon

    Spring Data works well for me.

  • gnasher729 (unregistered)

    1243 lines of identical code? That's amazingly excellent. Any lesser programmer than Rex would have ended up with 17 sets of around 1240 lines of almost identical but subtly different code.

  • gnasher729 (unregistered) in reply to Peter

    It's not that he misunderstood threads. He misunderstood singletons. Singletons: There can be only one. Not seventeen. Threadpool: Contains as many thread objects as you need.

  • nasch (unregistered)

    "There's just no universe in which 20 identical subclasses make sense"

    That's why it's on TheDailyWTF.com and not ITdecisionsThatMakeSense.com.

  • Simon (unregistered) in reply to Developer Dude

    Yeah, there's some interesting stuff happening in third-party libraries... the new Reactor-based APIs that are going into Spring, for example. But those APIs don't help much if the underlying resource is still synchronous... for example, they work well with a MongoDB store, since that natively supports async - but anything connecting to a traditional RDBMS is going to be stuck with blocking IO...

  • Jeff Grigg (unregistered)

    So assign the threading bug to Rex, and move on. Clearly, no one else is qualified (in Rex's mind) to work on such things.

    "Problem solved." >;->

  • Jeff Grigg (unregistered) in reply to Peter

    | "There's just no universe in which 20 identical subclasses make sense"

    Right! So refactor the 20 copies into a common base class, and have 20 [ completely pointless >;-> ] subclasses. There: "Problem solved; move on!" >;->

  • medievalist (unregistered) in reply to Developer Dude

    I was asked to work on a FOSS project by Red Hat, so I took a look at the code. It was heavily dependent on spring. So I looked at the source code for spring. Then I declined the offer.

Leave a comment on “A Tapestry of Threads”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article