1

Topic: CRITICAL_SECTION Together with Shared Memory

Kind time of days, dear colleagues! By development of our project, there was a necessity to work with great volume of storage. For this purpose - I applied Shared Memory (through API calls CreateFileMapping, MapViewOfFile etc.) . It is all perfectly works at an one-continuous variant. However, at multi-threaded when switching of pages through call MapViewOfFile happens from different (working) flows - problems take place. Application hangs up, during some moment at information handling. To reveal in more details - a debugger,  - it is not possible. To the reason of problems - me it is not clear yet. Probably problems of what actions with Shared Memory at me are protected (for a multi-threaded mode)  type CRITICAL_SECTION? At the same time, as at me all in one process, I consider application CRITICAL_SECTION  logical. For example here: http://www.cyberforum.ru/win-api/thread404316.html at all do not advise to work with Shared Memory in worker threads... Projection on physical-storage from the paging file and projection termination in flows is better not . I do not know, to what it is connected and whether there are here any restrictions. What thoughts in this respect here can be? P.S. In advance I thank for any answers!

2

Re: CRITICAL_SECTION Together with Shared Memory

Hello, AlexGin, you wrote: AG> What here there can be thoughts in this respect? AG> P.S. In advance I thank for any answers! And that they do? Different flows? Than are engaged? What circuit? One writer, it is full of readers? One reader, it is full of writers? The task in whole what?

3

Re: CRITICAL_SECTION Together with Shared Memory

Hello, Carc, you wrote: a C> Hello, AlexGin, you wrote: AG>> What here there can be thoughts in this respect? AG>> P.S. In advance I thank for any answers! A C> And that they do? Different flows? Than are engaged? A C> What circuit? One writer, it is full of readers? One reader, it is full of writers? The task in whole what? In an application operating time, worker threads read the information from Shared Memory. Only at application start - the unique worker thread writes all (from DB) in Shared Memory. Here - one "writer" working right at the beginning. This stage transits well. By operation of "readers" - problems take place.

4

Re: CRITICAL_SECTION Together with Shared Memory

Hello, AlexGin, you wrote: AG> However, at multi-threaded when switching of pages through call MapViewOfFile happens from different (workers) flows - problems take place. AG> application hangs up, during some moment at information handling. To reveal in more details - a debugger,  - it is not possible. I think it is necessary nevertheless a debugger  all flows. To install what of flows should continue operation and why it does not do it. If waits for something why this condition does not come and so on a chain to untwist.

5

Re: CRITICAL_SECTION Together with Shared Memory

Hello, zou, you wrote: zou> Hello, AlexGin, you wrote: AG>> However, at multi-threaded when switching of pages through call MapViewOfFile happens from different (workers) flows - problems take place. AG>> application hangs up, during some moment at information handling. To reveal in more details - a debugger,  - it is not possible. zou> I Think it is necessary nevertheless a debugger  all flows. To install what of flows should continue operation and why it does not do it. If waits for something why this condition does not come and so on a chain to untwist. I will try. Here while I clarify - like as a situation repeated enough that is already good.

6

Re: CRITICAL_SECTION Together with Shared Memory

Hello, AlexGin, you wrote: AG> Hello, Carc, you wrote: a C>> Hello, AlexGin, you wrote: AG>>> What here there can be thoughts in this respect? AG>>> P.S. In advance I thank for any answers! A C>> And that they do? Different flows? Than are engaged? A C>> What circuit? One writer, it is full of readers? One reader, it is full of writers? The task in whole what? AG> in an application operating time, worker threads read the information from Shared Memory. AG> Only at application start - the unique worker thread writes all (from DB) in Shared Memory. AG> Here - one "writer" working right at the beginning. This stage transits well. AG> by operation of "readers" - problems take place. If worker threads only read, and change nothing in SharedMemory  in section to turn? On which?  does not change? On mine here other circuit should be. Also depends on one: The unique flow if at once all writes, and is more there changes than nothing that and a fig then generally all ? If it all the same changes periodically something adds, and not just at start then it is necessary to synchronize flows. But only the writer with all readers and on the contrary. But in any time not to synchronize flows-readers among themselves, in it there is no necessity. They change nothing, and readers among themselves do not have necessity to be synchronized. 1) if worker threads have nothing to do, while the start flow does not add all,  then worker threads generally to start till the end of record? Then synchronization ! All wrote down, working flows-readers then launched. If in it to eat than be engaged, then it is simply got , and  the start flow, cocks it when all writes down. Flows-readers wait for it , and start to read, when it beeps. Though here it is better to wait to readers on two : 1st  speaks - "" to read, and the second "" to quit (well type the user pushed to close the program. 2) if the writer periodically something all the same changes a flow, generally differently. What-thread  - which speaks, how many flows read the data. While though someone reads, the flow-writer cannot start record over again. Flows readers - check what-thread two primitives (, )  it is pleasant to whom. 1st primitive signals on a subject what to read and at all it is impossible, there is a record by a flow-writer. 2nd primitive signals that records that while is not present, but it is impossible to read, since the writer gathers  in storage. As works: 1) the Flow the writer gathers  - and cocks , I want to write. 1.: the flow-reader checks this  - if sees that  to write - waits, does not start. 2) the writer checks a flow, whether is reading (on other semaphore) - if is waits while they will be completed. And when readers will be completed, they see point 1.. (Instead of whether want ) if want - do not read, wait. Sooner or later all active-readers complete old reading, and do not begin new reading. 3) a flow the writer learns that all readers finished reading. Also cocks another  - a whisker a pancake, I write to storage. Readers wait for both : and  "there is a record" and  "it is possible to start to read". 4) the writer stops to write the Flow and cocks two : "I stopped to write 1st" and "it is possible to read 2nd". Flows readers wake up, and start to read on a reading course increasing a semaphore "there is a reading". If during this moment the writer wants and still  a little (well is left thick what to do) - that he on a semaphore learns that while it is impossible to re-record the data -  still reads. But cocks  "I want to write". Then readers finish reading, but a rho  "I want to write" see that it is not necessary yet start to read anew, the flow-writer needs to unsubscribe and again wait. The main thing: It is a lot of flows of readers among themselves are not locked, and not  at all - for . They change nothing in storage, and will not hinder each other. Can read simultaneously. In general it ... Words here is difficult, and  and it is even more difficult. Such it is easy to draw on the circuit, on the chart - there all is simple. And words, I do not argue  it turns out. But somehow so.

7

Re: CRITICAL_SECTION Together with Shared Memory

Hello, AlexGin, you wrote: AG> Kind time of days, dear colleagues! AG> by development of our project, there was a necessity to work with great volume of storage. AG> for this purpose - I applied Shared Memory (through API calls CreateFileMapping, MapViewOfFile etc.) . AG> It is all perfectly works at an one-continuous variant. AG> however, at multi-threaded when switching of pages through call MapViewOfFile happens from different (working) flows - problems take place. AG> application hangs up, during some moment at information handling. To reveal in more details - a debugger,  - it is not possible. AG> to the Reason of problems - me it is not clear yet. AG> probably problems of what actions with Shared Memory at me are protected (for a multi-threaded mode)  type CRITICAL_SECTION? AG> At the same time as at me all in one process, I consider application CRITICAL_SECTION  logical. AG> for example here: AG> http://www.cyberforum.ru/win-api/thread404316.html AG> at all do not advise to work with Shared Memory in worker threads AG> AG>... Projection on physical-storage from the paging file and projection termination in flows is better not . AG> I do not know, to what it is connected and whether there are here any restrictions. AG> What here there can be thoughts in this respect? AG> P.S. In advance I thank for any answers! Similar - in one place clearing of critical section easier was not caused: LeaveCriticalSection (&pCore->m_csSMCore); that is - synchronization spoiled!

8

Re: CRITICAL_SECTION Together with Shared Memory

Hello, respected Carc, you wrote: Cs> If only read worker threads, and change nothing in SharedMemory  in section to turn? One of flows "" (on MapViewOfFile) page SharedMemory on page=0 (he should read from zero page); during the same time, another "" on page=1 (he should read from the first page) - however, previous that thinks that is selected zero P.S. I already specified in what an error was - I "overlooked" and did not deliver one of calls LeaveCriticalSection on one of (enough rare) algorithm branchings

9

Re: CRITICAL_SECTION Together with Shared Memory

AG> it is similar - in one place clearing of critical section easier was not caused: AG> AG> LeaveCriticalSection (&pCore->m_csSMCore); AG> AG> that is - synchronization spoiled! And what for pens? Is Scope Lock for this purpose. We do object on a stack which in the designer captures section, in  releases. Somehow so class CAutoCS {CRITICAL_SECTION& ref;//the link , any copyings, the guaranteed initialization in any designer public: CAutoCS (CRITITCAL_SECTION& _r):ref (_r) {EnterCriticalSection (&ref);//we enter into section} ~CAutoCS () {LeaveCriticalSection (&ref);//we release section} private: void* operator new (size_t);//and here you CAutoCS in a heap allocate a horse-radish!!! And any implementation! NEVER}// so int FunktsijaKotorajaChyotoGdeToTamDelaet (Vsjakie_Argumenty ...) {const CAutoCS auto_cs (exterior CRITITCAL_SECTION);//entered into section when resolved//...   did return __; //and on houses} fails and releases section Only this superfluous all. 1) if flows only read, but change nothing. Among themselves they should not be synchronized. Moreover, because of CRITITCAL_SECTION you it is simple  completely all multithreading, and there is nothing. While one flow reads, remaining anything cannot do. And could - all the same anything do not change. 2) CRITITCAL_SECTION a piece stupid enough, or yes or not. And to control it it is almost difficult. There are necessary more seriously synchronization, but it only if a flow-writer then, already after the first record, something  in MemoryShared on , to the third and so on wishes all the same and still time.

10

Re: CRITICAL_SECTION Together with Shared Memory

11

Re: CRITICAL_SECTION Together with Shared Memory

12

Re: CRITICAL_SECTION Together with Shared Memory

Hello, AlexGin, you wrote: AG>... AG> to Reveal in more details - a debugger,  - it is not possible. 1. At the moment of hangup to remove  process. It is possible directly from the manager of tasks, but it is even better utility ProcDump with a key-ma so in  it will be written down a helpful information maximum. 2. To open  in WinDBG, to execute a command! locks - it displays all critical sections captured at the moment of removal . It is already possible to analyze Further. In structure ntdll! _RTL_CRITICAL_SECTION the data about a flow which owns critical section (OwningThread), and also lockout meters and the recursive capture (LockCount and RecursionCount) is saved. 3. It is similarly possible to look stacks of all flows (a command ~ * kb) and  what hang on a call ntdll! RtlEnterCriticalSection. I.e. we take the first argument from a stack and it is executed such command: ' dt ntdll! _RTL_CRITICAL_SECTION argument '. 4. In a mode x64 the first 4 arguments are transferred through registers, to pull out them it is possible through cmkd (a plug-in for WinDBG to swing on www.codemachine.com). 5. Algorithm of action the following: we find the flows hanging on critical sections, we look OwningThread each section, we switch to appropriate flows and so to the victorious end, the "initial" flow-originator because of which all became will not be found yet further. Yes, and as already Carc wrote above, RAII - our all.

13

Re: CRITICAL_SECTION Together with Shared Memory

Hello, dear fellow countryman okman, you wrote: O> Hello, AlexGin, you wrote: AG>>... AG>> to Reveal in more details - a debugger,  - it is not possible. O> 1. At the moment of hangup to remove  process. It is possible directly from the manager of tasks, but still O> it is better utility ProcDump with a key-ma so in  it will be written down a helpful information maximum. I looked through ProcessExplorer, now still I will add to the arsenal and ProcDump! Thanks! O> 2. To open  in WinDBG, to execute a command! locks - it displays all critical sections, O> captured at the moment of removal . It is already possible to analyze Further. In structure O> ntdll! _RTL_CRITICAL_SECTION the data about a flow which owns critical section O> (OwningThread), and also lockout meters and the recursive capture (LockCount and RecursionCount) is saved. Debugging at me is debugger in composition MSVC-2015 (CE). Whether has sense to multiply entities? O> 3. It is similarly possible to look stacks of all flows (a command ~ * kb) and  what O> hang on a call ntdll! RtlEnterCriticalSection. I.e. we take the first argument from a stack and O> it is executed such command: ' dt ntdll! _RTL_CRITICAL_SECTION argument '. Where was specific it is executed this command - in what application? O> 4. In a mode x64 the first 4 arguments are transferred through registers, to pull out them it is possible O> through cmkd (a plug-in for WinDBG to swing on www.codemachine.com). At me all 32 bit. O> 5. Algorithm of action the following: we find the flows hanging on critical sections, O> we look OwningThread each section, we switch to appropriate flows, and O> so to the victorious end further, the "initial" flow-originator will not be found yet, because of O> which all became. It is all becomes in WinDBG? O> Yes and as already Carc wrote above, RAII - our all. Yes, I will look in this side - that here it would be possible to apply (probably and on what informed Carc)! Many thanks, dear fellow countryman okman, for so torn answer

14

Re: CRITICAL_SECTION Together with Shared Memory

Hello, AlexGin, you wrote: AG> Debugging at me is debugger in composition MSVC-2015 (CE). Whether has sense to multiply entities? It is everyone for itself solves. Personally I precisely have not enough possibilities of a debugger of a Visual Studio. And WinDBG is able very many, he should only to be able be "asked". AG> Where was specific it is executed this command - in what application? AG> it is all becomes in WinDBG? Yes.

15

Re: CRITICAL_SECTION Together with Shared Memory

Hello, AlexGin, you wrote: AG> P.S. In advance I thank for any answers! All  did not read attentively.  already advised? At whom , that also works with sharedmemory

16

Re: CRITICAL_SECTION Together with Shared Memory

Hello, CEMb, you wrote: CEM> Hello, AlexGin, you wrote: AG>> P.S. In advance I thank for any answers! CEM> All  did not read attentively. CEM> Mjuteksy already advised? At whom , that also works with sharedmemory For me all perfectly works at protection through CRITICAL_SECTION! If at me all becomes in the same process - what for to me heavy ? Z.Y.problem specified right at the beginning, is solved: simply in one place  call LeaveCriticalSection is forgotten

17

Re: CRITICAL_SECTION Together with Shared Memory

Hello, AlexGin, you wrote: AG> Thanks, I will look - the sensible piece can also it is not necessary to look. It is necessary to use. RAII our all. If the compiler supports 11th standard to use std:: mutex with std:: lock_guard.

18

Re: CRITICAL_SECTION Together with Shared Memory

Hello, AlexGin, you wrote: CEM>> Mjuteksy already advised? At whom , that also works with sharedmemory AG> For me all perfectly works at protection through CRITICAL_SECTION! AG> If at me all becomes in the same process - what for to me heavy ? AG> Z.Y.problem specified right at the beginning, is solved: AG> it is simple in one place  call LeaveCriticalSection Attention a question to "experts" is forgotten: if at you all this economy is protected by critical section,  generally all multithreading. If only one flow at any moment is fulfilled, and remaining only wait on section?

19

Re: CRITICAL_SECTION Together with Shared Memory

Hello, Carc, you wrote: a C> Attention a question to "experts": if at you all this economy is protected by critical section,  generally all multithreading. If only one flow at any moment is fulfilled, and remaining only wait on section? A counter question: And from what you decided, what at the HARDWARE under critical section all becomes? Under it there can be only any fast reading after which there are long "calculations".