• Ross Presser (google)

    I didn't wait, so now I'm frist

  • Pista (unregistered)

    We don't need no mutexes and flags. One single thread ought to be enough for anybody.

  • my name is missing (unregistered)

    This comment is busy, please wait for it.

  • (nodebb)

    To add insult to injury, they forgot to mark it volatile.

  • anonymous (unregistered)

    For a moment I thought the original author had discovered some little-known quirk of C# where function parameters are implicitly synchronised or volatile or something. Alas, no.

  • anonymous (unregistered) in reply to Medinoc

    I think that is the main issue with using a boolean as a lock (apart from the pass-by-value issue). I may be wrong but I'm pretty sure booleans in most languages are atomic, so mark it as volatile and you've got yourself a crude lock.

    That said, never actually do this. Any language designed for multithreading will already have properly-made locks.

  • (nodebb) in reply to Medinoc

    volatile wouldn't be enough even assuming that Busy was visible on some other thread. If you have multiple cores with separate caches (e.g. just about any modern PC) when the something that modifies Busy does so, it has to flush the cached value to main memory or threads operating in other cores won't see the change.

  • (nodebb)

    Given how bad the code is, it's probably better for everybody the rest of it doesn't get executed.

  • (nodebb)

    Maybe I'm missing something, but wouldn't Busy start out false, and get set to true after the loop, so it would NEVER wait.

  • Raj (unregistered) in reply to Pista

    That's what I love about nodejs. They have replaced confusing and challenging concepts like threads by an intuitive, user-friendly asynchronous architecture.

    Those first moments when you discover that your script doesn't wait for function calls to complete before moving to the next line are as priceless as the first time you try to exit from vi.

  • siciac (unregistered) in reply to BitDreamer

    It's whatever it was set to in the function, so the function either never waits or hangs.

    That's why locks are always an object, or you use some object whose attributes are marked as volatile.

    You can't mark arguments to a function as volatile; the whole point of pass by value is nothing else can change those values.

  • siciac (unregistered)

    "set to in the function" --> set to by the caller

  • (nodebb) in reply to siciac

    Agreed, that it would never wait or it would hang. But unless there's more WTF that's not shown, the only place Busy should be set is after checking it. So the only Busy ever set is the local variable.

    The calling function should never set Busy in a place that doesn't check it. And any place that's checking then setting it should not call any functions that would also lock on it. That's a different kind of WTF.

    Assuming the same pass by value WTF occurs wherever Busy is referenced, it would only ever be set to true on a local variable, so never true when passed to the function.

    It would never wait, unless there's even more WTF than shown.

  • (nodebb)

    https://xkcd.com/2138/

    I'll just leave this ^^^ here...

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Jeremy Pereira

    @Jeremy Pereira: Exactly. volatile should really only ever be used for things like memory-mapped I/O. It was never intended for thread synchronization. Not only are there the caching problems you mentioned, but a compiler can also reorder non-volatile reads/writes around volatile ones, so poorly written attempts at synchronization with volatile can lead to "impossible" bugs where certain memory values are in unexpected states.

    Busy waiting can be done correctly and safely using the proper primitives that provide documented guarantees about their memory model behavior (e.g. C11 <stdatomic.h>, C++11's <atomic>, or OS-specific primitives). But of course it's still busy waiting, and using proper mutexes is almost always preferable.

  • bvs23bkv33 (unregistered)

    halting problem solved!

  • ooOOooGa (unregistered) in reply to BitDreamer

    Of course 'busy' is going to be set before that 'while' statement. The calling code has to set something in the second parameter of the function call.

    currentFiles = GetMyList(someList, true, somePath, awesomeFile);

    In this case, 'busy' gets set to 'true' and the hang occurs.

    You are either trying to troll all of us, or you have never actually used functions in programming before.

  • Dyspeptic Curmudgeon (unregistered) in reply to Raj

    "Those first moments when you discover that your script doesn't wait for function calls to complete before moving to the next line are as priceless as the first time you try to exit from vi."

    You must belong to the cult of emacs. You guys just don't know how to :q

  • (nodebb) in reply to ooOOooGa

    No, not trolling. Serious conversation.

    Why would the calling function pass a fixed value of true? If it is, that's a totally different WTF. It should have a supposedly global variable, probably also called Busy, that should initially be false. If it's initially true, that's another WTF.

  • Thanatos (unregistered) in reply to BitDreamer

    because in most languages (and this looks like C# for me, where it is definitely the case), passing a bool as a method argument is done by copying the value. So it can never be changed externally after the method has been called. So it's either true, and we get an infinite loop, or it's false and it doesn't do anything. And in neither case does it do what the caller wanted.

    You can fix the issue with a global variable, but that means using a global variable, and that pretty bad. Or you could, you know, use the lock keyword, baked into the language for this very purpose and that doesn't make the thread use as much CPU as possible while waiting? C# and .net have so many useful multithreading/asynchronous helpers, yet people always reinvent the wheel. A square wheel.

  • Gumpy_Gus (unregistered)

    Well, I don't see that much of a problem. It's only going to hang HALF of the time, with random input. The function I'm currently working on hangs ALL the time.

  • (nodebb)

    The loyal followers of the One True Thread take great exception to your use of "Wait For It." That belongs exclusively to xkcd/1190

  • Bill Kempf (google) in reply to Jeremy Pereira

    The behavior of volatile will depend heavily on the language and/or the platform the code is run on. This appears to be C# code, in which case volatile ensures visibility even in the face of multiple caches. That's not to say that a busy wait is a good solution to thread synchronization, especially when implemented this naively, however.

  • (nodebb) in reply to Bill Kempf

    This appears to be C# code

    It's certainly highlighted as such.

  • Powehi (unregistered)

    This is actually an ingenious solution to the filenotfound Boolean state. It's simply waiting until the file can be found.

  • (nodebb) in reply to Bill Kempf

    Thanks.

  • Zanthra (unregistered) in reply to Raj

    Exiting VI is easy, it’s just

    :q[Backspace][Backspace][Esc]:q[Enter][Esc]:w[Enter]:q[Enter]

  • Barf4Eva (unregistered)

    For some reason this made me think of Rage Against the Machine..

    public static List<T> GetMyList<T>(this List<T> list, bool FuckYouIWontDoWhatYouTellMe, string FilePath, string FileName) { var myfilepath = FilePath + FileName; while (FuckYouIWontDoWhatYouTellMe) { // wait for it.. } … }

  • b.a. freeman (unregistered) in reply to Raj

    ... as priceless as the first time you try to exit from vi.

    :-D i have never used vi, but i still remember (after decades) that ":q" gets U out of it. it was a very hard lesson!

  • WTFGuy (unregistered)

    @ Powehi : Bravo!! You totally win the thread.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to Zanthra

    E37: No write since last change (add ! to override)

    Okay, vi, dammit, exclamation mark!

    :q![Enter]

    Actually my pet peeve is when I somehow manage to bring up the help as a sub-window. Then I have to quit from BOTH of them.

  • Inari (unregistered) in reply to Thanatos

    I think BitDreamer really just means that theres no reason for it to be passed while "true". Which isn't exactly correct though. Their thought seems to be that a calling function wouldn't itself set any Busy variable to true, because regardless of proper locking or not, that would cause a deadlock. As the caller couldn't continue until this function finished, but this function waits till the caller finishes.

    I'll post a reply to BitDreamer next though.

  • Inari (unregistered) in reply to BitDreamer

    I don't think you're entirely correct. The function that passes the value could be using a class value or something, which is correctly set to true or untrue by other pieces of code, but just in this particular case it's copied since you call a static function that can't access the value of the calling class. Whoever coded that then thought they'd just pass it and once it'll change to false, this will run, but since it's copied instead of referenced, that won't happen of course.

  • Inari (unregistered) in reply to Thanatos

    By the way, square wheels work well on certain floors ;)

  • Wizard (unregistered)

    "volatile" is one of those keywords which when starting a new job I search the code base for (along with #region, partial etc) to get an idea of the level of quality of the code/developer. Number of times I have seen idiots use volatile totally missing the point of what its for is frightening. Amazing how many dev's don't understand what atomic operation means when it comes to code....

Leave a comment on “Waaaaaiiiiit for it…”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article