- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Stop Poking Me!
- Operation Erred Successfully
- A Dark Turn
- Nothing Doing
- Home By Another Way
- Coast Star
- Forsooth
- Epic
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I didn't wait, so now I'm frist
Admin
We don't need no mutexes and flags. One single thread ought to be enough for anybody.
Admin
This comment is busy, please wait for it.
Admin
To add insult to injury, they forgot to mark it
volatile
.Admin
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.
Admin
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.
Admin
volatile
wouldn't be enough even assuming thatBusy
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 modifiesBusy
does so, it has to flush the cached value to main memory or threads operating in other cores won't see the change.Admin
Given how bad the code is, it's probably better for everybody the rest of it doesn't get executed.
Admin
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.
Admin
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.
Admin
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.
Admin
"set to in the function" --> set to by the caller
Admin
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.
Admin
https://xkcd.com/2138/
I'll just leave this ^^^ here...
Admin
@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.
Admin
halting problem solved!
Admin
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.
Admin
"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
Admin
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.
Admin
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.
Admin
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.
Admin
The loyal followers of the One True Thread take great exception to your use of "Wait For It." That belongs exclusively to xkcd/1190
Admin
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.
Admin
It's certainly highlighted as such.
Admin
This is actually an ingenious solution to the filenotfound Boolean state. It's simply waiting until the file can be found.
Admin
Thanks.
Admin
Exiting VI is easy, it’s just
:q[Backspace][Backspace][Esc]:q[Enter][Esc]:w[Enter]:q[Enter]
Admin
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.. } … }
Admin
... 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!
Admin
@ Powehi : Bravo!! You totally win the thread.
Admin
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.
Admin
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.
Admin
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.
Admin
By the way, square wheels work well on certain floors ;)
Admin
"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....