[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


File: cirnocomputer9.png (284 KB, 800x600)
284 KB
284 KB PNG
Why isn't there a system call to tell the kernel that a certain piece of code is uninterruptible? this would eliminate race conditions once and for all
>>
It doesn't works like that, son
>>
>>107693305
No, it wouldn't. Cpus can run multiple operations at the same time. Ever heard of cpu cores?
>>
>>107693305
Place a sock upon your cock.
>>
>>107693356
why not? I know my idea sounds stupid, and there's probably a reason for it and I would like to know it
>>107693389
I was thinking that "uninterruptible" would also forbid more than one core from accessing the relevant code covered by that system call
>>
It would freeze the entire system until done. The entire system.
>>
>>107693305
https://en.wikipedia.org/wiki/Halting_problem
>>
>>107693305
go contribute to locking if you want to eliminate race conditions?
>>
>>107693499
sounds like windows 11 on my work laptop
>>
>>107693705
Sounds like you laptop is shit, get a better job
>>107693305
That's why you don't drop from school,.at least should post this on >>>/g/sqt
>>
>>107693305
The race condition problem is caused by you forgetting to use semaphores or locks or other similar mechanisms.
If you make a system call like this, you will forget to use it as well.
>>
>>107693305
>this would eliminate race conditions once and for all
It wouldn't though. You may or may not have noticed, but they aren't called "being interrupted conditions", they're being called "race conditions" instead, and there's a very good reason for that. "Being interrupted" isn't even in the top 10 causes of race conditions.
>>
>>107693720
sure, the laptop is the problem, not the pajeetware 11
>>
>>107693764
Works on my current and previous machine, new one has Core Ultra 7 H155, 32gb ram, 2tb nve, never had a single issue so far
>>
>>107693305
futex
>>
>>107693446
You can't lock memory to cores like that. A thread can jump between cores. Thread scheduling isn't just hurr durr use this core.
>>
>>107693932
my laptop also has ultra 7 (cant remember exact model), 64gb ram and 2tb nve but pajeetware 11 is slow and buggy
>>
>>107694014
Might be a layer 8 problem
>>
>>107693305
you should use a real time OS if you absolutely need these safety guarantees
any lesser use case is just a skill issue and you shouldve taken parallel computing in undergrad
>>
>>107693305
I think you could fix race conditions by banning niggers.
>>
>>107693305
Just go back to 8bit computing!, there's no race conditions there!

Until you're doing anything anything remotely decent with graphics, then interrupts like VSYNC WILL act like a second thread, and you WILL get race condition problems, and now you will have to deal with em using 8bit assembly.
>>
>>107693305
You can eliminate race conditions (and nulls) by using a better type system.
>>
>>107693305
>system call to tell the kernel that a certain piece of code is uninterruptible
This could conceivably be implemented but maybe not with acceptable performance.
It would also rely on the programmer using those calls at the right times, and since they already misuse mutexes etc there might not be much hope of that.
>>
>>107693446
if you can make a thread uninterruptible, think of what would happen if you make a mistake that leads to an infinite loop.

though it depends on what you mean precisely: 'no other thread of process X can interrupt thread Y of process X' VS 'no other thread can interrupt thread Y of process X'

In the first scenario, that's not really a problem, but in the second scenario, this can be a real issue (e.g whole system becomes unresponsive)

Multi-threading used to work like that:
https://en.wikipedia.org/wiki/Cooperative_multitasking
But we've moved on to use preemptive scheduling which doesn't have this whole system freezes problem.

Even when you use mutexes perfectly, you still may encounter data races/raceconds with other resources, like the filesystem. There are special mutexes for those, but locking a file can lead to new problems (e.g deadlocking another process that needs to access the file).

>>107694324
There are no fundamental solutions that fix race conditions. Even Rust has race conds, it's type system was only designed to prevent data races. Anyway as soon as you talk to an external component (server, filesystem, database), you introduce invariant that are too complex to clearly express in the type system.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.