Forums before death by AOL, social media and spammers... "We can't have nice things"
|    sci.electronics.design    |    Electronic circuit design    |    143,326 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 142,952 of 143,326    |
|    Don Y to bitrex    |
|    Re: Call by reference protection    |
|    20 Feb 26 16:16:44    |
      From: blockedofcourse@foo.invalid              On 2/20/2026 3:25 PM, bitrex wrote:       > On 2/20/2026 12:47 PM, Don Y wrote:       >       >> I use CoW to implement call-by-value semantics on objects that       >> would typically be passed as call-by-reference. E.g., imagine       >> anObject is a single frame of video and operator() is going to       >> apply a masking function to it, eliding all but the "important"       >> parts of the frame for return to the caller.       > Similar to how GPUs do, if the operator() can perform its required       calculations       > on a const reference to the data but its output can be reduced to operations       on       > individual pixel values of integral type which don't depend on the output       value       > of neighboring pixels std::atomic is for that situation, and should be lock       > free for processors that have hardware support for atomics e.g. ARM v6 and       later              That depends on the nature of the operation(s) being performed.              If a service relies on another service to perform its desired       operation, then you end up holding locks for long periods of time.       Not the case for a GPU where it has lots of resources to devote       to its very specific functionality.              E.g., in the file server example, accepting a "request" and then       invoking a synchronous call to the local file system ties up that       thread for a long time as it now is blocked waiting for the       file system to complete the requested task. (imagine if the       requested file resided on a remote server or on slow media).              To regain any sense of performance, you'd have to rely on using multiple       (kernel, not POSIX) threads so another could be available to handle       another request while the first is blocking. Lather, rinse, repeat.              I.e., it is often better to make (or simulate) an asynchronous call       to any other services required so you can release the thread for       "other work" while that is being processed. This, of course, makes       the design a bit more delicate as YOU now have to keep track of how       many balls you are juggling.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca