Poll of the Day > fuck race conditions.

(+) Yeah! (+)

If you're writing software and your API tells me you're done processing a command you better fucking be done processing that command.
---

Don't get me started on inclement weather.
---

Some of the races are on difficult courses.
---

Here: https://en.wikipedia.org/wiki/Race_condition
---

Rainbow Road is always the hardest.
---

I don't understand the usage of race in this context.
---

Yea Allied Races are bullshit. Just let me play them if I bought the expansion. None of this reputation grinding bullshit

my race is harder than yours
---

Probably one of the most infamous failures involving a race condition was the Therac-25, a radiation therapy machine. If the operator selected the wrong mode then changed it within a few seconds, it could set off a race condition in the computer that could fire the machine at 100 times the normal dose of beta radiation. Three patients died from radiation poisoning, others suffered radiation burns.
---

Lokarin posted...

I don't understand the usage of race in this context.

if you use multi-threading, or other scenarios where the same code can be executed more than once simultaneously by two difference threads/processes, the actual order in which the instructions execute is unknown (each execution context will occur in its own order, but they will all be interleaved together in some random way). in particular this means that you can't rely on a read of a variable staying true until the next instruction (at least if there are also writes to that variable, which is one reason why immutability (readonly variables) is desirable). race condition specifically is saying "whoever gets there first wins", and the problem is you never know who will get there first.
---

Seems like a multi-threading problem? God, my last multi-threading project was a nightmare. I actually gave up. Not something to throw in as an afterthought.

---

Sahuagin posted...

Lokarin posted...

I don't understand the usage of race in this context.

if you use multi-threading, or other scenarios where the same code can be executed more than once simultaneously by two difference threads/processes, the actual order in which the instructions execute is unknown (each execution context will occur in its own order, but they will all be interleaved together in some random way). in particular this means that you can't rely on a read of a variable staying true until the next instruction (at least if there are also writes to that variable, which is one reason why immutability (readonly variables) is desirable). race condition specifically is saying "whoever gets there first wins", and the problem is you never know who will get there first.

Interesting, but it seems like outcome dependent events should be single-threaded for that exact reason... even if it creates a small bottleneck for the multithreading events before it
---

Lokarin posted...

Interesting, but it seems like outcome dependent events should be single-threaded for that exact reason... even if it creates a small bottleneck for the multithreading events before it

You cannot guarantee that everything is single threaded.
Also you do not want everything to be single threaded.
I am currently integrating with a third party application. Basically I tell it to do something (Send this file to this place) and then I tell it to stop sending files after I believe it's completed. The problem is that I have no way to tell its completed (beyond the fact that my file is no longer there. I either have to wait a period of time (This is NEVER a good idea) and then tell it to stop, or I have to find some way to ask it if it has done transferring my file.
As far as I can tell there's no way to ask it if it's done transferring my file.
---

Judgmenl posted...

Lokarin posted...

Interesting, but it seems like outcome dependent events should be single-threaded for that exact reason... even if it creates a small bottleneck for the multithreading events before it

You cannot guarantee that everything is single threaded.
Also you do not want everything to be single threaded.
I am currently integrating with a third party application. Basically I tell it to do something (Send this file to this place) and then I tell it to stop sending files after I believe it's completed. The problem is that I have no way to tell its completed (beyond the fact that my file is no longer there. I either have to wait a period of time (This is NEVER a good idea) and then tell it to stop, or I have to find some way to ask it if it has done transferring my file.
As far as I can tell there's no way to ask it if it's done transferring my file.

I'm a dullard, but maybe this will help?

https://www.youtube.com/watch?v=IP-rGJKSZ3s
---

Lokarin posted...

I'm a dullard, but maybe this will help?

People who aren't me should write better code so I can actually interface with them.
---

Lokarin posted...

Interesting, but it seems like outcome dependent events should be single-threaded for that exact reason... even if it creates a small bottleneck for the multithreading events before it

any time two processes try to share a resource (usually memory), the same problems emerge, so it doesn't necessarily require multi-threading

Judgmenl posted...

You cannot guarantee that everything is single threaded.
Also you do not want everything to be single threaded.
I am currently integrating with a third party application. Basically I tell it to do something (Send this file to this place) and then I tell it to stop sending files after I believe it's completed. The problem is that I have no way to tell its completed (beyond the fact that my file is no longer there. I either have to wait a period of time (This is NEVER a good idea) and then tell it to stop, or I have to find some way to ask it if it has done transferring my file.
As far as I can tell there's no way to ask it if it's done transferring my file.

what language and API?

not the best solution, but a starting point, can you just spin with "while file exists" or something?

are you sure there isn't a callback function you can pass, or a promise or something (or use await, depending on the language)?
---

Lokarin posted...

I'm a dullard, but maybe this will help?

that problem seems more related to networking. at lower levels, sending packets uses UDP (nicknamed "unreliable data protocol") where there is never a guarantee that anything you send will be received at the other end, and in fact you will never know if it was or wasn't received.

built on top of this is TCP, which is a reliable protocol and has features designed to fix this issue. (in particular, confirmations that messages are being received, as well as timeouts so that if a confirmation is missed, the message can be sent again, as well as sequence numbers so that messages arriving out of order or with duplicates can always be properly assembled and any missing pieces can be re-requested.)
---

Sahuagin posted...

what language and API?

not the best solution, but a starting point, can you just spin with "while file exists" or something?

are you sure there isn't a callback function you can pass, or a promise or something (or use await, depending on the language)?

I'm doing REST stuff (Well the RPCs are REST based at least) in Python.
Anyways, I think the problem was that I was restarting their application too much. I am generating different configurations and restarting. Seems to not like multiple restarts within 10 seconds of each other.
My main tech stack right now is Python/C/Go.
---

i agree, fuck affirmative action
---

Judgmenl posted...

I'm doing REST stuff (Well the RPCs are REST based at least) in Python.
Anyways, I think the problem was that I was restarting their application too much. I am generating different configurations and restarting. Seems to not like multiple restarts within 10 seconds of each other.

I dunno if it's worth asking since I can't see what you're doing, and I don't have tons of experience with REST, but for the sake of conversation and interest, shouldn't this REST API be running on a server or something? why are you restarting it at all? shouldn't it be a service?
---

My product at work in multi-threaded and it is a pain to manage.
---

Code is scary stuff!

---

Krazy_Kirby posted...

i agree, fuck affirmative action

This is called employment equity in Canada, and only applies federally. I always thought you were English for some reason.
---