home bbs files messages ]

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