5 ms·

"For the purposes of this discussion I’m going to assume a generic version of sleep() that accepts a parameter representing time in milliseconds. The concepts s

"For the purposes of this discussion I’m going to assume a generic version of sleep() that accepts a parameter representing time in milliseconds. The concepts scale up or down with the scale of the parameter." Nice write-up, but no version of sleep() accepts a parameter representing time in milliseconds. Many embedded platforms have no sleep() function. Most recently, I had to implement it (and usleep) on MSP-430.

oralty 8y ago
Oh dear, you sound quite confused. https://linux.die.net/man/3/usleep https://linux.die.net/man/3/usleep https://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/n... Which is POSIX, which is supported by a number of OSes, such as QNX, Linux, BSDs, and countless others. https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-sleep https://docs.microsoft.com/en-us/windows/desktop/api/synchap... http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf See page 43 on "Standard Profile" https://www.ee.ryerson.ca/~courses/ee8205/Data-Sheets/Tornado-VxWorks/vxworks/ref/taskLib.html#taskDelay https://www.ee.ryerson.ca/~courses/ee8205/Data-Sheets/Tornad... MSP-430 is not an OS, it is a microcontroller, so your comment makes absolutely no sense. Ironically one of the most popular open source MSP-430 OSes is FreeRTOS.. which of course has vTaskDelay. Like name an OS (RTOS or otherwise) that does not have an API to sleep for millisecond periods? Not saying none exist, but, it's probably easier to name the exceptions.
- com2kid 8y ago
  > Like name an OS (RTOS or otherwise) that does not have an API to sleep for millisecond periods? ooh! I worked on one. Cooperative multithreading, you could schedule a task (callback function) to be called in 'n' hundreds of microseconds. There was a scheduler that would drop the entire CPU to a super low power state if no tasks were scheduled to happen anytime soon (and set a HW timer to wake the CPU when more tasks were going to come due), but there was no "user land" API to sleep the entire system. Sleeping the entire system when battery life is important (better to do as much work during each CPU wake cycle as possible, then drop back down to super low sleep for extended periods of time), and when other code needs to run, is rather rude, so we didn't allow it.
  - oralty 8y ago
    Nothing in the generic spec for a "sleep" function specifies you can't drop to a low power state if there is nothing to do. To varying degrees that is how sleep functions work on general purpose OSes. The CPU doesn't just spin for extended periods of time when there is nothing to do (it may spin for short waits). A "schedule a task to be called in 'n' hundreds of microseconds" is effectively a "sleep" function, the use of an explicit callback (PC) vs implicitly saving the PC of the thread is a mere implementation detail.
    - com2kid 8y ago
      It served a similar purpose, if no one else scheduled anything anytime soon. The schedule task function in this particular embedded OS actually didn't guarantee it'd call you at the specified timeout, the contract was that it'd invoke the callback no sooner than the specified timeout! Timer coalescing and all that. Irritated the heck out of the traditional embedded engineers when they first got introduced to it though. "I know this operation will take this many microseconds, can't I just sleep until it is done and the results are waiting for me?" Not allowed! Plenty of old school engineers are used to just spinning the CPU while waiting for something to happen!
      - oralty 8y ago
        > didn't guarantee it'd call you at the specified timeout, the contract was that it'd invoke the callback no sooner than the specified timeout! This is the contract for sleep on just about every general purpose OS preemptive or cooperative, and what would be assumed in the original article. > I know this operation will take this many microseconds, can't I just sleep until it is done and the results are waiting for me?" I mean now we're just conflating so many things. What you describe here is the essence of a hard real-time OS. It's quite orthogonal to the issue of ensuring low power. Since there are plenty of systems that require both. > Plenty of old school engineers I can assure you there are plenty of old school engineers that can get an MCU to run for months on a couple AA batteries. They're not spinning a 20MHz CPU in a busy-loop most of the time.
- ananonymoususer 8y ago
  I am not confused, but perhaps you did not understand my meaning. There is no version of "sleep()" that accepts an argument in anything other than seconds. Of course Microsoft has "Sleep()" which does, and of course "usleep()" and "nanosleep()" do. Is this unclear?

oralty 8y ago

Oh dear, you sound quite confused. https://linux.die.net/man/3/usleep https://linux.die.net/man/3/usleep https://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/n... Which is POSIX, which is supported by a number of OSes, such as QNX, Linux, BSDs, and countless others. https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-sleep https://docs.microsoft.com/en-us/windows/desktop/api/synchap... http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf See page 43 on "Standard Profile" https://www.ee.ryerson.ca/~courses/ee8205/Data-Sheets/Tornado-VxWorks/vxworks/ref/taskLib.html#taskDelay https://www.ee.ryerson.ca/~courses/ee8205/Data-Sheets/Tornad... MSP-430 is not an OS, it is a microcontroller, so your comment makes absolutely no sense. Ironically one of the most popular open source MSP-430 OSes is FreeRTOS.. which of course has vTaskDelay. Like name an OS (RTOS or otherwise) that does not have an API to sleep for millisecond periods? Not saying none exist, but, it's probably easier to name the exceptions.

com2kid 8y ago
> Like name an OS (RTOS or otherwise) that does not have an API to sleep for millisecond periods? ooh! I worked on one. Cooperative multithreading, you could schedule a task (callback function) to be called in 'n' hundreds of microseconds. There was a scheduler that would drop the entire CPU to a super low power state if no tasks were scheduled to happen anytime soon (and set a HW timer to wake the CPU when more tasks were going to come due), but there was no "user land" API to sleep the entire system. Sleeping the entire system when battery life is important (better to do as much work during each CPU wake cycle as possible, then drop back down to super low sleep for extended periods of time), and when other code needs to run, is rather rude, so we didn't allow it.
- oralty 8y ago
  Nothing in the generic spec for a "sleep" function specifies you can't drop to a low power state if there is nothing to do. To varying degrees that is how sleep functions work on general purpose OSes. The CPU doesn't just spin for extended periods of time when there is nothing to do (it may spin for short waits). A "schedule a task to be called in 'n' hundreds of microseconds" is effectively a "sleep" function, the use of an explicit callback (PC) vs implicitly saving the PC of the thread is a mere implementation detail.
  - com2kid 8y ago
    It served a similar purpose, if no one else scheduled anything anytime soon. The schedule task function in this particular embedded OS actually didn't guarantee it'd call you at the specified timeout, the contract was that it'd invoke the callback no sooner than the specified timeout! Timer coalescing and all that. Irritated the heck out of the traditional embedded engineers when they first got introduced to it though. "I know this operation will take this many microseconds, can't I just sleep until it is done and the results are waiting for me?" Not allowed! Plenty of old school engineers are used to just spinning the CPU while waiting for something to happen!
    - oralty 8y ago
      > didn't guarantee it'd call you at the specified timeout, the contract was that it'd invoke the callback no sooner than the specified timeout! This is the contract for sleep on just about every general purpose OS preemptive or cooperative, and what would be assumed in the original article. > I know this operation will take this many microseconds, can't I just sleep until it is done and the results are waiting for me?" I mean now we're just conflating so many things. What you describe here is the essence of a hard real-time OS. It's quite orthogonal to the issue of ensuring low power. Since there are plenty of systems that require both. > Plenty of old school engineers I can assure you there are plenty of old school engineers that can get an MCU to run for months on a couple AA batteries. They're not spinning a 20MHz CPU in a busy-loop most of the time.
ananonymoususer 8y ago
I am not confused, but perhaps you did not understand my meaning. There is no version of "sleep()" that accepts an argument in anything other than seconds. Of course Microsoft has "Sleep()" which does, and of course "usleep()" and "nanosleep()" do. Is this unclear?