Re: Windows CE Threading questions
- From: "Tarundeep Singh Kalra" <tarundeep<at>GMAIL.COM>
- Date: Mon, 10 Apr 2006 11:57:45 +0530
see more info in -
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcemain4/html/cmconinterruptlatencies.asp
--
Thanks In Advance
Tarundeep Singh Kalra
www.tarunsadhana.com
"John Eldridge [MSFT]" <johneld@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23ADpbbbVGHA.5496@xxxxxxxxxxxxxxxxxxxxxxx
There are a couple of layers to the low physical memory handling in the CE
kernel.
The first is triggering an Out Of Memory (OOM) event when an
OEM-customizable RAM threshold is reached. This allows the system to
display a dialog box (again OEM-customizable) perhaps asking the user to
shut down applications. Alternately the OOMUI component could take other
automatic action for a headless device, for example.
The next step is reclaiming RAM where possible. For instance, memory
mapped files can be flushed to storage and the RAM pages freed. In
addition, to answer your specific question, yes, automatic stack
scavenging can occur to reclaim stack pages that are now out of scope.
OEMs can customize this as well to prevent high priority real-time threads
from having their stacks reclaimed.
The final guard is that all RAM requests, with the exception of stack
commit, will start failing in the kernel prior to being completely out of
memory. This allows some reserved buffer for stacks to auto-commit.
If you blast past all three barriers and use ALL RAM pages, the kernel
will cease to function. You can certainly craft a "perfect storm" to cause
this to happen, but in real life it's a rare occurence.
Also, note, this is for just the CE kernel. A Windows Mobile system has
some other higher-level defenses in place to hibernate or close
applications in the background to avoid out of memory conditions.
--
Thanks,
John Eldridge
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Michael J. Salamone" <mikesa#at#entrek#dot#com> wrote in message
news:uDVe5QaVGHA.2276@xxxxxxxxxxxxxxxxxxxxxxx
Inline.
--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com
"AC" <ac@ac> wrote in message
news:OZUJh3XVGHA.2492@xxxxxxxxxxxxxxxxxxxxxxx
thanks, that covers my question.
for curiousity - what happens if the system is low on physical
memory and more stack memory must be "autoo-committed"?
Will the OS prevent that from happen by not scheduling that
thread, or will the process be terminated or what happens?
Most apps will crash and hopefully be terminated. But, depending on
where it specifically happens, you might take down the system. For
example, perhaps a thread in the device manager takes the exception.
You also need to be aware of the max stack size (64K in your example).
Even if there is physical memory to commit more than 64K, the system
won't. If the thread tries to go beyond 64K, you get a stack overflow
exception.
also, can memory be "auto-decommitted" in case the thread
needs less physical memory (exeample if returning from
a function that used almost the max stack size)?
No auto-decommit. If you have a function that needs a lot of stack,
consider getting it off the heap instead. Which, itself, incidentally,
also has auto-commit, but not auto-decommit. If that's a problem, you
can create a private heap within that function, or VirtualAlloc directly,
and then destroy the heap or VirtualFree directly.
"Michael J. Salamone" <mikesa#at#entrek#dot#com> wrote in message
news:OabmOwIVGHA.1868@xxxxxxxxxxxxxxxxxxxxxxx
Clarification: when the stack is created, vm is reserved in the
process - enough for the max stack size (64K in your case). 4K is
initially committed (needs RAM). More is auto-committed as required by
the thread's actual stack needs.
--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com
"Yannick Chamming's [eMVP]" <ychammings_nospam@xxxxxxxxxx> wrote in
message news:elh84iIVGHA.6048@xxxxxxxxxxxxxxxxxxxxxxx
Allocation is only in virtual address space. However, due to 32MB per
process memory limitation, it generates a limitation of 512 threads in
the same process.
--
----------------------------------------------------------------
Yannick Chamming's (eMVP)
ADENEO (ADESET)
Windows Embedded Manager
ychammings AT adeneo DOT adetelgroup DOT com>
http://www.adeset.com
Tél : +33 (0)4.72.18.57.77
Fax : +33 (0)4.72.18.57.78
----------------------------------------------------------------
"AC" <ac@ac> a écrit dans le message de news:
ehPB9JIVGHA.5588@xxxxxxxxxxxxxxxxxxxxxxx
ok thank you. But what about memory usage for
creating thread (my other question reposted below)?
If I call CreateThread to create a thread with default stack size,
it seem that the stack size is 64 kB. But is that only allocated
in virtual address space? Or does calling CreateThread mean
that 64 kB physical memory is allocated? Seems like CE hasn't
a page file like windows xp has, so that's why I wonder this.
.
- References:
- Re: Windows CE Threading questions
- From: AC
- Re: Windows CE Threading questions
- From: Michael J. Salamone
- Re: Windows CE Threading questions
- From: John Eldridge [MSFT]
- Re: Windows CE Threading questions
- Prev by Date: Re: timesvc problem synchronizing time
- Next by Date: Re: Launch(UINT32 pFunc) function at startup.s
- Previous by thread: Re: Windows CE Threading questions
- Next by thread: Re: Windows CE Threading questions
- Index(es):
Relevant Pages
|
