I can write threaded code



  • A long time ago the designers of our application attempted to make it multi threaded, and failed. So the code is in place, but the number of threads is configured as one.

    I was asked to make our single threaded application multithreaded so as to reduce the footprint. That is, instead of 20 instances each with a multi GB cache footprint, run one instance with multiple threads and share a cache.

    Then I got into the code.

    First, they used Spring to create the db connection pool. No problem. Then they wrote their own connection pool manager. And they wrote it incorrectly: it leaked connections. So close.

    Next, they wrote "beans" (cough) - with every method and local variable public and static (OO anyone?)

    In the code, they load the beans via Spring (getBean) in one place, and simply instantiate them (via new) everywhere else (consistency anyone?)

    Since there were problems with the original threaded code, the developer put in strategically placed sleep's in order to keep the program from tripping over itself. And the sleep's were cpu-speed dependent, so when they upgraded hardware two years ago, the timing changed, and strange bugs cropped up. SVN blame says the only changes were to the sleep-times.

    Finally, there were the singleton objects with unsynchronized public non volatile static variables that were supposedly thread-safe. Of course every thread would just trample the values set by every other thread.

    When I asked the developer who wrote it how it was supposed to be thread safe given what he had written, he replied: "I can write threaded code, but for some reason it just didn't work."

    I then attempted to show him why it didn't work, but he insisted that "the JVM is supposed to keep all that stuff straight".

    sigh

     



  • @snoofle said:

    I then attempted to show him why it didn't work, but he insisted that "the JVM is supposed to keep all that stuff straight".

     

     

    The tool does the job, in stead of the tool helps me to do the job - classic IT failure. Yeah that is the kind of thinking that separates the programmer from the developer.



  • @snoofle said:

    "the JVM is supposed to keep all that stuff straight".

    Sounds to me like a...

    *puts on sunglasses*

    threadbare excuse.

    YYYYEEEEEEAAAAAAAAAAAAAAAAA



  • @snoofle said:

    "the JVM is supposed to keep all that stuff straight".

    Wrap [url=http://docs.oracle.com/javase/6/docs/api/java/lang/ThreadLocal.html]ThreadLocal[/url]s around everything, then he can be slightly closer to correct!



  •  @snoofle said:

    A long time ago the designers of our application attempted to make it multi threaded, and failed. So the code is in place, but the number of threads is configured as one.

    I was asked to make our single threaded application multithreaded so as to reduce the footprint. That is, instead of 20 instances each with a multi GB cache footprint, run one instance with multiple threads and share a cache.

    Then I got into the code.

    First, they used Spring to create the db connection pool. No problem. Then they wrote their own connection pool manager. And they wrote it incorrectly: it leaked connections. So close.

    Next, they wrote "beans" (cough) - with every method and local variable public and static (OO anyone?)

    In the code, they load the beans via Spring (getBean) in one place, and simply instantiate them (via new) everywhere else (consistency anyone?)

    Since there were problems with the original threaded code, the developer put in strategically placed sleep's in order to keep the program from tripping over itself. And the sleep's were cpu-speed dependent, so when they upgraded hardware two years ago, the timing changed, and strange bugs cropped up. SVN blame says the only changes were to the sleep-times.

    Finally, there were the singleton objects with unsynchronized public non volatile static variables that were supposedly thread-safe. Of course every thread would just trample the values set by every other thread.

    When I asked the developer who wrote it how it was supposed to be thread safe given what he had written, he replied: "I can write threaded code, but for some reason it just didn't work."

    I then attempted to show him why it didn't work, but he insisted that "the JVM is supposed to keep all that stuff straight".

    sigh

     

     

    Thats actually worse than at our place... where a pool of threads all operate on, and share numerous resources which basically make the whole multi-threaded effort pointless. Yet support still tell customers to increase the thread count as step 1 in the process for solving performance issues. It doesn't help, but it makes customers feel special and like we're listening (And makes support feel like they know something - which they don't).

     



  •  put @Configurable in every Bean, so you can keep the new everywhere :D



  • @erikal said:

    the kind of thinking that separates the programmer from the developer.
     

    While I agree with the sentiment you're trying to convey, unfortunately there are no formal definitions of programmer and developer that we can agree upon that places the two in a hierarchy of sorts, so I really can't know which of the two you consider superior. I wager the developer. Am I right?



  • A programmer is someone that cracks open the VBA editor in word and fiddles with a macro

    A developer is the person that they call to come and fix it and make it work properly



  • @dhromed said:

    @erikal said:

    the kind of thinking that separates the programmer from the developer.
     

    While I agree with the sentiment you're trying to convey, unfortunately there are no formal definitions of programmer and developer that we can agree upon that places the two in a hierarchy of sorts, so I really can't know which of the two you consider superior. I wager the developer. Am I right?

     

    You are correct on both accounts. I would have compared programmer and architect to make a more clearly defined separation in skill level, but that is an equally vague description. Generally I interpret it as "programmers write code", "developers create solutions". The term "to develop" indicates an actual developed end product, "to program" only says something about twisting nobs and pushing buttons :)



  •  Distinguishing between "men" and "boys" tends to work quite fine. :)



  • To me, developers are a blanket term describing a pool of people (with different roles) working towards development of a product. They could be Biz Analysts (gathering requirements), Architects (designers), programmers (coders), testers (quality assurance), deployment (release managers), project managers (or team leaders), etc.

    However, most organisations tend to refer to people by their role - more descriptive of their expected duties and responsibilties. Developers and programmers and coders sometimes get lumped into the same category, unfortunately. I know of one place where architecture is performed by the "senior developers", as though length of service is a prerequisite for a change in duties.



  • @dhromed said:

     Distinguishing between "men" and "boys" tends to work quite fine. :)


    Well, no. Some of the best developers I ever knew were female. Though admittedly, one of the worst male programmers I ever knew did have a sex change not long after he stopped being a programmer (he/she became a sales type person). As I recall, the two events were not actually related, they just happened to occur at about the same time.



  • @snoofle said:

    "I can write threaded code, but for some reason it just didn't work."

    If it doesn't work (for any reason), then apparently you [i]can't[/i] write threaded code.



  • @Cad Delworth said:

    Well, no. Some of the best developers I ever knew were female.

    Bizarrely, two of the best sysadmins I've taught were female. Was in Solaris, mind, but they had cautious and perceptive viewpoint on administration, compared to the "loose cannon" attitude of the blokes. Fair warmed my heart, it did.



  • @Cad Delworth said:

    As I recall, the two events were not actually related, they just happened to occur at about the same time.

    It definitely is the weirdest / funniest non-sequitur I've read so far this year. :-)

     



  • @boog said:

    @snoofle said:

    "I can write threaded code, but for some reason it just didn't work."

    If it doesn't work (for any reason), then apparently you can't write threaded code.

     

     As we have seen many, many times on this site, it is absolutely possible (if not common) to write any type of code that doesn't work.



  • @snoofle said:

    When I asked the developer who wrote it how it was supposed to be thread safe given what he had written, he replied: "I can write threaded code, but for some reason it just didn't work."

    I then attempted to show him why it didn't work, but he insisted that "the JVM is supposed to keep all that stuff straight".

    sigh

     

    Wow. Even SpectateSwamp is laughing at that one. That would be one hell of a VM. What else can the JVM do? Wax your car and seduce beautiful women?



    I've never heard anyone say anything quite as ignorant as that, but I did have a colleague protest to me, during a whiteboard session, that code from one thread would not enter into code from another .cs file because that code "belonged to a different thread". That is, he was actually confusing assembly boundaries - and even mere source file boundaries - with thread boundaries.



    My response was something like, "how do you think threads do I/O if they're really restricted to this one little .cs file?" His response to that was something along the lines of "Mike's done a lot of work with threading. Let me go get him and we'll see what he says."

    @snoofle said:

    Finally, there were the singleton objects with unsynchronized public non volatile static variables that were supposedly thread-safe.

    Well, that could be true. If you take all of those static variables and use them to implement Lamport's Bakery Algorithm, for example, then your code will be thread safe.



  • @Cad Delworth said:

    As I recall, the two events were not actually related, they just happened to occur at about the same time.

    Another race condition!

     



  • @bridget99 said:

    @snoofle said:
    Finally, there were the singleton objects with unsynchronized public non volatile static variables that were supposedly thread-safe.

    Well, that could be true. If you take all of those static variables and use them to implement Lamport's Bakery Algorithm, for example, then your code will be thread safe.

    Not without making at least one or two of them volatile, I would think.




  • @bridget99 said:

    What else can the JVM do? Wax your car and seduce beautiful women?
     

    People have been clamoring for that feature for years, so Java 8 will no doubt provide a clunky means of waxing women and seducing beautiful cars.



  • @Someone You Know said:

    @bridget99 said:

    What else can the JVM do? Wax your car and seduce beautiful women?
     

    People have been clamoring for that feature for years, so Java 8 will no doubt provide a clunky means of waxing women and seducing beautiful cars.

     

    Don't diss the stuff before it is released. You have no way of proving it will be clunky, it might be wonderfully slick, shiny and easily injected.



  • @snoofle said:

    Next, they wrote "beans" (cough) - with every method and local variable public and static (OO anyone?)

     

    I find that hard to believe, especially if you are talking about entity beans and not just session beans.  They never needed to represent two different records from the same DB table at the same time? 

    I know it's too much to expect unit tests, but probably the third or fourth unit test they would have written would have been to get two entity bean instances at the same time ...


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.