• Frist (unregistered)


  • (nodebb)

    Sharing is caring!

  • and? (unregistered)

    I don't know how this article is supposed to be even moderately educational or amusing. Any developer with actual work experience had his own share of cases like that,unless we are talking about an extremely lucky person. Next time on TDWTF: numbers in critical database table that were supposed to be equal didn't match each other. Be amazed at the horror!

  • pif (unregistered) in reply to and?

    I agree! Ask your money back!

  • Puzzl´d (unregistered)

    Yes, I also want and?´s money back! (because shared state and all, his/her money is also mine. I call a mutex on the money, guys!).

  • Mike a Person (unregistered)

    I have removed code that tried to implement a networked serial number generator using a file stored on a Microsoft file server DFS group drive where unsynchronised copies of the same file can exist momentarily.

    Several hundred lines of code replaced with using simple queries to an SQL database server. It was thought to be 'hard' to use the SQL server...

  • and? (unregistered)

    shared state -> state where everything is shared everything is shared -> communism x -> kiss. mutex -> mute kiss. or silent kiss? money back -> yenom. Yer Nom. Your name? And the money is mine. like an explosive device used to blow people up. So, someone wants me and my identity, because he lives in communist state and is blowing people up with explosives. He summons a kiss, silently, to guys, and that involves money. that's some weird, weird stuff...

  • Qazwsx (unregistered) in reply to and?

    ...who's havin' buttsex?

  • Or. (unregistered) in reply to and?

    I'm just too lazy to dig out our old code that used that kind of logic and clearness of semantics.

  • xor! (unregistered) in reply to Qazwsx

    But transmissible spongiform encephalopathy kiss?

  • NAND (unregistered)

    How do you even create a 'Singleton' that spans several VMs? I assume the 'Singleton' is a shared VM?

    P.S. I lied on the I'm not a robot CAPTCHA.

  • Melnorme (unregistered)

    Maybe he thought Singleton = ThreadLocal?

  • Been there, done that... (unregistered) in reply to and?

    You've actually created the problem you were trying to avoid?

    On how many projects did it happen for you? And how far along during the project did you discover this? And, for each project, can you tell us what the project specific issue was?

  • Developer Dude (unregistered)

    Unfortunately way too many devs have no clue regarding concurrency.

    When I started at my current position, I found the app I was to work on (a Swing desktop app) had SwingWorkers calling SwingWorkers 5 levels deep. That was just one of the many symptoms I found that indicated most devs who worked on this app didn't understand Java concurrency best practices.

  • Jeremy Hannon (google)

    I worked on an app that had the opposite problem. The developers did not understand thread management. They knew just enough that on a new TCP session to spin up a new thread to handle it - which included all of the SQL I/O. They also realized to keep the conversation going that they needed to keep the TCP/IP connection alive for a period of time since there was no good way to be certain the client was done with the session. Their solution to avoid issues was one socket per thread, keeping that thread alive for the entire timeout period.

    Since this was .Net and using the default thread pool with default settings, eventually (often) the number of concurrent threads waiting for data exceeded the pool and new connections would just queue up. Since the users thought they were "stuck", they would restart the app/request leaving the initial request to take up its full timeout length in the pool and their new request to move to the end of the line... obviously a never ending cycle. Their solution was to simply spread out the users by geographical area to more and more servers and to restart one when it locked up like this.

    I went in and enhanced the thread management so that it only took a thread from the pool when there was actual I/O, which then allowed everyone across the half dozen servers to run on a VM that was idle most of time. At least they didn't have concurrency issues, though... at least not with that part of the system.

  • (nodebb) in reply to NAND

    I read it that there would be one test suite, running on the host or another VM, that connects to multiple VMs to run tests. It should be able to run tests concurrently otherwise you'll have to wait a long time it they had to run one after the other.

    My concurrency problem at the moment involves test servers that are supposed to be self contained but share an authentication server. These are each controlled by a central Jenkins server. Each server does not know anything unique about itself. When the test involves creating a username, with the suite in use, there's a non-zero chance of creating a duplicate username between them. So we get a lot of false-negative results on our build because of "username exists" errors. (Not to mention a heap of other fragile tests mostly because of tests not cleaning up properly but that's a whole other problem!)

  • (nodebb)

    I remembered that once upon a time, one of our new hires in one of my ex-company told me that we should use "GET" to send data to the web browser and use "POST" to pull data from the browsers... //faceplam

    Addendum 2016-09-14 21:55: The internet indeed was full of false information back then.

  • (nodebb)

    If dropping a hammer sometimes smashes your toe, you should take careful aim with the hammer in the future, to ensure it smashes your toe.

  • (nodebb) in reply to cheong

    I think you'll find that the Internet is still full of false information...

  • ChrisEvansForBakeOff (unregistered) in reply to Steve_The_Cynic

    Indeed. For example, this comment is completely wrong.

  • "Martin" (unregistered)

    Whoo, that got an upgrade in terribleness. The original problem was that tests using multiple VMs had to run time-consuming setup code sequentially. There was no (easy) way to introduce (additional) coupling between independent test slaves!

    So far as mutexes, I only wish "Jackson" had bothered. Everything just got funneled through one Firefox window with no cooperative multithreading by default. We only had any of that at all because without it, the setup failed really obviously. The protection against fighting over the window later in the test was "don't write code that touches multiple VMs through Selenium. It's scary." (Keep in mind, it's still a delicate operation to mix access to the VMs in single-threaded code under this model, if there's anything involving modals or the like.)

    Another detail I know I didn't include: "Jackson" didn't get kicked out. He got poached by another company.

  • Norman Diamond (unregistered)

    Addendum 2016-09-14 21:55: The internet indeed was full of false information back then.

    It's not so full any more. The internet has expanded a bit so there's plenty of room for more.

  • (nodebb) in reply to ChrisEvansForBakeOff

    Oh, I miss the days when you can still click "Like" for the replies. :)

  • (nodebb) in reply to cheong

    Yeah me too.

Leave a comment on “Learning to Share”

Log In or post as a guest

Replying to comment #:

« Return to Article