> so the thing to do is actually to drop a level. not to try to be a higher-level engineer, but to almost drop a level and simply become the greatest teammate for a while.
Thanks, this is going to be my answer to “what’s you first 30 days plan” question.
It is very difficult to tell at the moment. We don’t know what is the upper limit of AI’s capabilities.
If it happens that AI is able to replace say 25% of the office workforce (including programmers of course). The result could be catastrophic, if governments do not step in and do something. It could definitely lead to a depression and another world war, given that we already have some regional wars in the Middle East and Eastern Europe.
I found myself fascinated by two topics -- Synchronization and Virtual File System in kernel land. Do they have similar websites? I know SunOS was the first one who implemented VFS and they wrote a white paper about it back in the 90s.
Who did it is irrelevant. The more important thing is who the propaganda is blaming. Then we know what the elites (behind this piece of propaganda) want.
I think most of us are not worrying about AI killing us like the terminators, but taking over our job and killing us slowly. Or, at least disrupting the global society enough that a hot war has a 10% of chance to occur in the next 20-30 years, which...actually seems quite plausible, even without AI.
Like, 80% of the people out there gotta be below average (not median) and very replaceable.
Thanks for sharing. Can someone tell me what does this paragraph mean?
> Use a lock where you tell the system that you're waiting for the lock, and where the unlocking thread will let you know when it's done, so that the scheduler can actually work with you, instead of (randomly) working against you.
I have “implemented” a sleep lock in xv6. Is it what he meant? What does the Linux scheduler “know” about it and will do differently? (Trying to figure out what does “work with you” mean)
In simplest terms: if you don’t tell the kernel that you’re waiting, the scheduler assumes you aren’t and will wake you up and let you spin, to the detriment of other threads that aren’t waiting.
If the OS knows that a thread is waiting for a lock, the scheduler will not bother to schedule it until the lock is available.
In general, it’s tempting when you’re bound by lock latency to skip the syscall overhead of sleeping. But a lot of the time that’s a code smell that there are other inefficiencies in the system and you should rethink how you’re scheduling work.
The basic idea is that a lock should be something the OS is aware of, so that while a thread is blocked on a lock, the scheduler never tries to wake it at all, and when it is unlocked, the scheduler can wake up the thread that's waiting on it immediately. If the scheduler isn't aware of the lock, it'll just try to wake up the thread periodically, often just wasting CPU when it's still blocked or kept asleep when it could be running.
I think he means that if the OS knows about locking, it can manage a list of "waiters" to quickly know which thread to wake (resp. let sleep) once (resp. before) the lock is released.
Thanks, this is going to be my answer to “what’s you first 30 days plan” question.
reply