3 ms·

This is a confusing article. The main content is a description of how to implement a simple operating system scheduler which effectively is implementing locks u

This is a confusing article. The main content is a description of how to implement a simple operating system scheduler which effectively is implementing locks using instruction level primitives. The author has completely neglected the most common cases where either "tasks" require multiple resources (e.g. when copying between two files) or where the ordering of tasks is important. It is these two conditions that lead to deadlocks and livelocks.

sterlind 8y ago
Most (though not all, see Midori) OSes use preemptive multitasking and threads. These tasks are cooperating coroutines - a different beast. Of course you can use tasks to implement a thread scheduler, but this machinery would probably live in a user-mode runtime. As for the neglected cases, you can build those out of these primitives: canonical ordering of tasks for multiple resource acquisition; work stealing and/or a DAG executor where ordering is important. My only criticism is that it's a little redundant to implement both mutexes and semaphores - a mutex is just a semaphore of 1. But the rest is wonderful.
- plasticchris 8y ago
  Mutex is for resource locking, semaphore is for signaling. This means they have some differences in implementation extending beyond simply limiting semaphore to get a mutex.
  - jamescostian 8y ago
    AFAIK, the only difference between "semaphore of 1" and "mutex" is that a semaphore is definitely able to be signaled by someone who isn't holding a lock, whereas a mutex is sometimes only able to be signaled/unlocked by whoever acquired the lock. As long as you trust the code running on your machine (if you don't, you have bigger issues to worry about), you'll be fine - nobody signals a semaphore before waiting on it if they're hoping to achieve mutual exclusion
SlowRobotAhead 8y ago
>to be able to do extra work at the end of the task, we wrap our task into a task that call the given tasks and performs the extra work Yea, a bit confusing. He surely knew what he meant but I didn’t. Given the prevalence of mutexes and semaphores in embedded I was hoping to take something useful away, but yea the issue is I have no other work to do. I can’t do anything really until this read or write or access is done. I can’t write here until this read is finished not because of access but logically I need input to determine output, etc. A bit different from your comment, but similar lines i think.
gpderetta 8y ago
It is a scheduler, but it is different from a typical OS scheduler. On most OSs, when a thread locks a mutex it keeps running on its original CPU, it is not suspended and resumed in the CPU that last locked that mutex (which would be an approximation for the behaviour of this architecture).

sterlind 8y ago

Most (though not all, see Midori) OSes use preemptive multitasking and threads. These tasks are cooperating coroutines - a different beast. Of course you can use tasks to implement a thread scheduler, but this machinery would probably live in a user-mode runtime. As for the neglected cases, you can build those out of these primitives: canonical ordering of tasks for multiple resource acquisition; work stealing and/or a DAG executor where ordering is important. My only criticism is that it's a little redundant to implement both mutexes and semaphores - a mutex is just a semaphore of 1. But the rest is wonderful.

plasticchris 8y ago
Mutex is for resource locking, semaphore is for signaling. This means they have some differences in implementation extending beyond simply limiting semaphore to get a mutex.
- jamescostian 8y ago
  AFAIK, the only difference between "semaphore of 1" and "mutex" is that a semaphore is definitely able to be signaled by someone who isn't holding a lock, whereas a mutex is sometimes only able to be signaled/unlocked by whoever acquired the lock. As long as you trust the code running on your machine (if you don't, you have bigger issues to worry about), you'll be fine - nobody signals a semaphore before waiting on it if they're hoping to achieve mutual exclusion

SlowRobotAhead 8y ago

>to be able to do extra work at the end of the task, we wrap our task into a task that call the given tasks and performs the extra work Yea, a bit confusing. He surely knew what he meant but I didn’t. Given the prevalence of mutexes and semaphores in embedded I was hoping to take something useful away, but yea the issue is I have no other work to do. I can’t do anything really until this read or write or access is done. I can’t write here until this read is finished not because of access but logically I need input to determine output, etc. A bit different from your comment, but similar lines i think.

gpderetta 8y ago

It is a scheduler, but it is different from a typical OS scheduler. On most OSs, when a thread locks a mutex it keeps running on its original CPU, it is not suspended and resumed in the CPU that last locked that mutex (which would be an approximation for the behaviour of this architecture).