Re: Heap memory available (W32 console app in Visual C++)
CriCri <bitwyse@leTIRETmaquis.net> wrote:
You seem to misunderstand how critical sections work. All threads
accessing the same shared data must do so under the same critical
section, otherwise it won't help any. You can't enforce proper access
synchronization from just one thread - all threads must cooperate.
You seem to have a different understanding of "critical sections"
from me.
I understand it in the sense of Win32 CRITICAL_SECTION structure, as
manipulated by EnterCriticalSecion, LeaveCriticalSection and related
APIs.
In my terms (as a low-level assembly language programmer,
having written a multi-tasking kernel) the start of a critical
section is marked by a mutex and until it is cleared no other thread
can aquire the CPU.
Perhaps such a facility exists in the kernel mode, but not in a
user-mode Win32 process. Acquiring a mutex (or critical secion), only
blocks threads that try to acquire the same mutex (or critical section).
There's no global system-wide mutex you can grab and block every other
process in the system.
Anyway, we still haven't determined whether the 'data' - the heap - is
really shared or not.
Heap as the data structure is not shared. Virtual address space is not
shared. Physical memory and disk space are most certainly shared.
If one single process malloc()'s one byte (OK - it will probably take
4, neatly aligned) is the entire Windows memory management system
updated?
Yes, if the allocation necessitates requesting a new physical memory
page from the OS.
Now, how do you plan to get all other processes in the system to use
your critical section whenever they allocate memory?
I don't. Memory management under Windows doesn't seem to be very
intelligent and I can't fix that.
It is rather intelligent, in that it prevents one badly written (or
malicious) user-mode process from freezing the whole system. I shudder
to think of the consequences of actually having the system-wide
stop-CPU-dead mutex you are speaking of.
Of course not. But all processes do share the same physical memory
chips installed on the motherboard, and the same swap file on the
same physical hard drive.
So if there is not enough memory available to start a new process with
'normal' memory requirements, the system should say so immediately and
refuse.
So you expect that the system would reserve 2GB of memory for every new
process, whether it needs it or not? I suggest you start Task Manager,
count the number of running processes on the Processes tab, multiply
that by 2GB, and compare the result with the amount of memory you have
installed in your machine.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925