- An argument *against* (the liberal use of) references - 4 Updates
- Does anynone see what's so speial about this loop ? - 1 Update
- Windows Process Tree - 4 Updates
| Juha Nieminen <nospam@thanks.invalid>: Nov 23 06:52AM > proper synchronization, the object may be changed by another thread at > any moment, for example in the middle of the copy operation, and thus > the copy might become internally inconsistent. I think you have a point there. I was thinking that since the function is getting a local copy of the object then mutual exclusion problems go away because that local copy is completely independent of the original. I didn't think that *copying* the object for the function in itself isn't automatically thread-safe. Yet still, for a few seconds, I had the strong instinct that there has to be something "more thread-safe" about making a copy of the value for the function than have the function take a reference to it... but the more I try to figure out how, I fail. Copying merely moves the mutual exclusion problem to a slightly different place, but it doesn't solve it. The calling code *still* needs to solve the mutual exclusion problem regardless of which way the function takes the parameter. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 23 01:51PM +0100 On 23 Nov 2022 07:52, Juha Nieminen wrote: > but it doesn't solve it. The calling code *still* needs to solve the > mutual exclusion problem regardless of which way the function takes the > parameter. Depends on when the copying is done. Copying to the tread instantiation is safe. - Alf |
| Juha Nieminen <nospam@thanks.invalid>: Nov 23 01:46PM >> parameter. > Depends on when the copying is done. > Copying to the tread instantiation is safe. If you are calling a function and giving as parameter a variable that may be modified by another thread, you need to take care of the mutual exclusion problem regardless of whether that function takes the parameter by value or by reference. I originally didn't think about the fact that the function taking it by value doesn't solve the problem because now copying the value needs the mutual exclusion. The only thing that happens is that the point of potential conflict has been moved to a slightly different place. You could make a local copy of the value before passing it to the function (which could be quite efficient if the variable is atomic), but even then it doesn't really matter if the function takes it by value or by reference. (OTOH this may be much more efficient if the function takes a significant amount of time because you don't need to keep the mutex locked for the duration of the function.) |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 23 08:08PM +0100 If you don't need an iterated or indexed access with a pointer you'd better use a reference since you can't have any accidental modifications on the reference. And references have the advantage that you can pass temporaries to them. With operator overloading you can't use pointers instead. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 23 04:50PM +0100 for( BOOL (WINAPI *getProcess)( HANDLE, LPPROCESSENTRY32W ) = Process32FirstW; ; ) { PROCESSENTRY32W pew; pew.dwSize = sizeof(PROCESSENTRY32W); if( !getProcess( xhSnapshot.get(), &pew ) ) break; processes.emplace_back( pew, true, process_it(), process_it() ); getProcess = Process32NextW; } |
| DFS <nospam@dfs.com>: Nov 22 11:11PM -0500 On 11/22/2022 3:16 PM, Bonita Montero wrote: > I developed a little program which lists the process tree of Windows. Where's the output? Does it look like the data from SysInternals pslist64.exe? https://imgur.com/zYcFpRk |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 23 08:11AM +0100 Am 23.11.2022 um 05:11 schrieb DFS: > Where's the output? > Does it look like the data from SysInternals pslist64.exe? > https://imgur.com/zYcFpRk Similar, but I only show the executable name and the process ID. |
| Muttley@dastardlyhq.com: Nov 23 08:15AM On Tue, 22 Nov 2022 21:16:29 +0100 >I developed a little program which lists the process tree of Windows. [snip usual Bonita mess] >The process tree is built inside a single vector and printed with a >recursive lambda. Thank god you didn't write task manager. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 23 01:27PM +0100 > [snip usual Bonita mess] If that is a mess for you this is rather a statement about you. > Thank god you didn't write task manager. It would be much more safe and efficient - for no practical reason. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment