3 ms·

How do you insert a branch "every 10ms" without some sort of hardware-provided interrupt? If your code is running in a hot loop, you would have to insert that

How do you insert a branch "every 10ms" without some sort of hardware-provided interrupt? If your code is running in a hot loop, you would have to insert that branch into the hot loop (even well-predicted branches add a few cycles, and can do things like break up decode groups) or have the hot loop bail out every once in a while to go execute the branch and code, which would mean tiling your interior hot loop and thus adding probably significant overhead that way. Also, you say "cached memory address" but I can almost guarantee that unless you're doing that load a lot more frequently than once every 10 milliseconds the inner loop is going to knock that address out of l1 and probably l2 by the time you get back around to it.

hedora 1y ago
You put the check outside the innermost loop. Put it up one or two loops instead, and reason that the check runs frequently enough and also infrequently enough. Also, don’t you have to hit a pthread cancellation point for pthread_cancel to take effect? Those are way more expensive than a branch, but if you want the exact behavior, you could do “if (done) { break; } else { pthread_??? }”
- pengaru 1y ago
  > Also, don’t you have to hit a pthread cancellation point for pthread_cancel to take effect? No, the whole point here is async cancellation - you don't test for it and you don't enter a cancellation point. Excerpt from pthread_setcancelstate(3): > Asynchronous cancelability > Setting the cancelability type to PTHREAD_CANCEL_ASYNCHRONOUS is rarely useful. > Since the thread could be canceled at any time, it cannot safely reserve resources > (e.g., allocating memory with malloc(3)), acquire mutexes, semaphores, or locks, and > so on. Reserving resources is unsafe because the application has no way of knowing > what the state of these resources is when the thread is canceled; that is, did cance- > lation occur before the resources were reserved, while they were reserved, or after > they were released? Furthermore, some internal data structures (e.g., the linked > list of free blocks managed by the malloc(3) family of functions) may be left in an > inconsistent state if cancelation occurs in the middle of the function call. Conse- > quently, clean-up handlers cease to be useful. > > Functions that can be safely asynchronously canceled are called async-cancel-safe > functions. POSIX.1-2001 and POSIX.1-2008 require only that pthread_cancel(3), > pthread_setcancelstate(), and pthread_setcanceltype() be async-cancel-safe. In gen- > eral, other library functions can't be safely called from an asynchronously cance- > lable thread. > > One of the few circumstances in which asynchronous cancelability is useful is for > cancelation of a thread that is in a pure compute-bound loop.

hedora 1y ago

You put the check outside the innermost loop. Put it up one or two loops instead, and reason that the check runs frequently enough and also infrequently enough. Also, don’t you have to hit a pthread cancellation point for pthread_cancel to take effect? Those are way more expensive than a branch, but if you want the exact behavior, you could do “if (done) { break; } else { pthread_??? }”

pengaru 1y ago
> Also, don’t you have to hit a pthread cancellation point for pthread_cancel to take effect? No, the whole point here is async cancellation - you don't test for it and you don't enter a cancellation point. Excerpt from pthread_setcancelstate(3): > Asynchronous cancelability > Setting the cancelability type to PTHREAD_CANCEL_ASYNCHRONOUS is rarely useful. > Since the thread could be canceled at any time, it cannot safely reserve resources > (e.g., allocating memory with malloc(3)), acquire mutexes, semaphores, or locks, and > so on. Reserving resources is unsafe because the application has no way of knowing > what the state of these resources is when the thread is canceled; that is, did cance- > lation occur before the resources were reserved, while they were reserved, or after > they were released? Furthermore, some internal data structures (e.g., the linked > list of free blocks managed by the malloc(3) family of functions) may be left in an > inconsistent state if cancelation occurs in the middle of the function call. Conse- > quently, clean-up handlers cease to be useful. > > Functions that can be safely asynchronously canceled are called async-cancel-safe > functions. POSIX.1-2001 and POSIX.1-2008 require only that pthread_cancel(3), > pthread_setcancelstate(), and pthread_setcanceltype() be async-cancel-safe. In gen- > eral, other library functions can't be safely called from an asynchronously cance- > lable thread. > > One of the few circumstances in which asynchronous cancelability is useful is for > cancelation of a thread that is in a pure compute-bound loop.