• Edd (unregistered)

    Last comment

  • Hanzito (unregistered)

    If the standard HashMap would have been thread safe, it wouldn't have made a difference, I think: both calls to get() can be evaluated at different moments.

    I also doubt the linter was triggered by this construction. I suspect it was triggered by the != in the condition.

  • (nodebb) in reply to Hanzito

    Try getting the food from the fridge. If food exists, look at it, put it back, close the fridge, then open it again, and get the food from the fridge, then eat.

  • RLB (unregistered) in reply to Hanzito

    I also doubt the linter was triggered by this construction. I suspect it was triggered by the != in the condition.

    Since the warning apparently went away with the change, that seems right. I've never seen a linter intelligent enough to find the real WTF in such code, just silly style points.

  • RLB (unregistered)

    Even if the concurrency weren't a problem, this line is still wrong for efficiency reasons. Every function call takes time, memory, and whatnot. Yes, it may well be very little - but when the code that calls fewer functions is also cleaner, that's not premature optimisation.

  • Pabz (unregistered) in reply to Mr. TA

    That's true, it could also happen that in between you closing the fridge and opening it again someone else has opened the fridge, taken the food and closed the fridge :)

  • NotAThingThatHappens (unregistered) in reply to RLB

    Just take a look in the mirror.

  • I am not robot (unregistered)

    sounds like TRWTF is that configItems can change at runtime - surely if there's one candidate for a collection that should be immutable, you'd expect it to be the config?

  • Ruts (unregistered) in reply to I am not robot

    Immutable? No thanks - I would very much like to be able to change configuration dynamically, without forcing an application restart.

  • (nodebb) in reply to I am not robot

    surely if there's one candidate for a collection that should be immutable, you'd expect it to be the config?

    Depends which config it is. If it's some sort of "site config" (classpath, which libraries are where, that sort of stuff), then yes, it should be invariant while the program is running, but the double search is still a WTF since the search is not free. (It doesn't cost much, but it doesn't cost zero either.)

    If, on the other hand, it's "user config", then yes, it might change at runtime, in which case the table of config items would need to be protected, and there will be code somewhere that reloads it.

  • 516052 (unregistered) in reply to Ruts

    Kid these days. Next thing you'll want some sort of inbuilt menu screen with all the options listed for easy understanding and changing as well.

    Why, back in my day when we wanted to change config files we had to go in and manually change bits of the code and than refire the whole exe. And than we had to get the [strike]slaves[/strike] interns to carry all the plates up the zigurat uphill both ways.

    I miss those days.

  • I'm not a robot (unregistered)

    There's no race condition here that wouldn't also be present in the simplified version. If it tries to fetch from the map while the other thread is making a change, then either version may crash or otherwise behave unpredictably. Otherwise, there are three possibilities:

    1. The other thread makes its change before this line calls .get() for the first time, in which case the result will be equal to the post-change value, which can also happen with the simplified code.

    2. The other thread makes its change after this line calls .get() for the last time, in which case the result will be equal to the pre-change value, which again can happen with the simplified code.

    3. The other thread makes its change in between the two calls to .get() in this line (which implies the first call must have returned non-null, otherwise there wouldn't be two calls in the first place). In that case. the end result will once again be equal to the post-change value.

    So, as long as the simultaneous read/write scenario doesn't occur, both versions of the code will produce a result consistent with running either entirely before or entirely after the change. If one of those possibilities is undesirable, then both versions of the code would need extra synchronisation to prevent that from happening.

  • OldCoder (unregistered) in reply to I'm not a robot

    That is all very well, but remember, the other thread will also be making two calls!

  • Sole Purpose Of Visit (unregistered) in reply to Steve_The_Cynic

    I think I'd at least want a snapshot on the config. I don't really care whether I get a config from right now or from several seconds ago ... just as long as it's consistent.

    Just another tick-box left unchecked in the OP, It's What The Turtles all the way down, young man ....

  • Barry Margolin (github)

    @I'm not a robot is correct. The ternary would only add an additional bug if it returned a different default value than null.

  • Andy Miller (unregistered) in reply to 516052

    Interns? Luxury ! We used to have to update the config live on the disc by hand using a magnetised needle, including the checksums

  • jay (unregistered)

    I just came across a line of code yesterday that wanted to pass "userid", which was declared as a GUID, to a function. So the programmer wrote:

    whatever_the_function_name_was(new Guid(userid.toString())

    i.e. start with a guid. Convert it to a string. Then convert the string back to a guid.

  • jay (unregistered)

    "We used to have to update the config live on the disc by hand using a magnetised needle" You used disks? In my day when we wanted to change data, we had to glue the chads back into the punch cards and then punch out new holes.

  • jay (unregistered)

    " open it again, and get the food from the fridge, then eat." There's a "code pattern" used frequently at my company that drives me nuts. When they want to retrieve multiple records, they first do a query to get the IDs of all the records that meet the desired condition. Than they write a loop in code that loops through these IDs, and for each, reads the record from the database and adds it to an array or list. Then they loop through the list to process the records.

  • King (unregistered)

    And this is how Schrodinger's cat was discovered.

  • Gabe (unregistered)

    Am I reading the "fixed" line right? If value is null, output null, otherwise output value. In other-words, the fix version barring race conditions will always output null?

  • Sole Purpose Of Visit (unregistered) in reply to jay

    Checksums? Luxury! When I was the Senior Paper Chain Engineer, we would have bled to death for a checksum!

    Back then, we fed in whatever bits of cardboard we could stitch together, and waited for the customer to complain two days later that we'd just fed them gibberish. And then t'customer would thrash us to death wit'his belt.

    (I did however manage to write a boot processor for a Perkin Elmer that took the first boot stage -- on paper tape -- and produced the second boot stage -- on paper tape -- which produced the third boot stage -- again on paper tape. Then I literally sellotaped the three bits together.

    (I was pointlessly proud of that achievement. I still am.)

  • Sole Purpose Of Visit (unregistered) in reply to King

    Or ... was it?

  • Race Conditions (unregistered)

    The sad part about race conditions is you can't even use them to detect race conditions, because of the flip side that they often work.

  • 516052 (unregistered) in reply to Andy Miller

    Ah, magnets. I remember back when those were invented. Really made things much easier. Sadly they also took away much of the magic.

    There just is nothing like watching a bunch of [strike]slaves[/strike] unpaid interns walking half naked up the side of a zigurat with man sized baked clay tablets of cunieform binary on their backs to plop them in on top like a giant toaster.

    I remember back in the day working on a big accounting project for I think it was the sumerians (or was it the Hittites, I forget). We had this giant pottery kiln that could fit 40 or 50 tablets all at once. And that thing was running 24/7. With interns runing in and out trying to push the slabs out with sticks like a giant piza oven. It was glorious.

    Sadly than the bronze age collapse came and next thing you know everyone is using PHP.

  • Dave (unregistered) in reply to 516052

    https://www.woodyguthrie.org/Lyrics/Biggest_Thing_That_Man.htm

    Biggest Thing That Man Has Ever Done - (aka. The Great Historical Bum) Words and Music by Woody Guthrie

    I'm just a lonesome traveler, The Great Historical Bum. Highly educated from history I have come. I built the Rock of Ages, 'twas in the Year of One And that was about the biggest thing that man had ever done.

    I worked in the Garden of Eden, that was the year of two, Joined the apple pickers union, I always paid my due; I'm the man that signed the contract to raise the rising sun, And that was about the biggest thing that man had ever done.

    I was straw boss on the Pyramids, the Tower of Babel, too; I opened up the ocean let the migrant children through, I fought a million battles and I never lost a one, And that was about the biggest thing that man had ever done.

    Etc.

  • Argle (unregistered)

    I once took over a project done in C. I think I submitted the whole story once, but I'll just mention here that I noticed that warnings were turned off completely. I figured I could turn it on and have some clues what might be wrong. Rebuilt it and watched warnings scroll off the top of my screen at a pace to fast to read. I watched a couple minutes of this before finally hitting Ctrl-C. Someone pulled a Wheatley and ended impending doom by shutting up the alerts.

  • Smartass (unregistered)

    The real WTF here is that Java requires its users to know that Hashmap is not thread safe, and that the consequence is a subtle bug that is near-impossible to replicate, and totally impossible to find by code inspection.

  • Smartass (unregistered)

    The real WTF here is that Java requires its users to know that Hashmap is not thread safe, and that the consequence is a subtle bug that is near-impossible to replicate, and totally impossible to find by code inspection.

  • nasch (unregistered)

    Imagine the chutzpah of expecting developers to be familiar with the platform they're using.

  • (nodebb) in reply to Gabe

    Am I reading the "fixed" line right? If value is null, output null, otherwise output value.

    Yes...

    In other-words, the fix version barring race conditions will always output null?

    ... and no; if the value is not null, it will output the non-null value (barring race conditions, as you said).

    If it said "if value is null, output value, else output null", that would have the behaviour you describe. But it's not as broken as all that.

Leave a comment on “Retern your Linter”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article