CE 4.2 and CE 5.0 devices hang if using shared virtual memory during active IO

CE 4.2 and CE 5.0 devices hang if using shared virtual memory during active IO

Post by Vyacheslav » Fri, 22 Dec 2006 01:24:58



In our application we use shared virtual memory a lot via custom operator
new/delete. It works OK and allows us to use all available physical memory
if needed (so we are not limited to 32 MB).

But if the cpu load is high and we actively use RS232 port and also write to
the flash card then the devices just hang in several minutes.
It was tested on our own platforms and on HP iPAQs. Application hangs under
de *** and ActiveSync looses connection.

So it can be either problem in our memory allocation or really problem in
hardware or OS. What could it really be?
 
 
 

CE 4.2 and CE 5.0 devices hang if using shared virtual memory during active IO

Post by Paul G. To » Fri, 22 Dec 2006 02:08:49

I'd say that it's most likely to be your fault. What do you mean by "shared
virtual memory"? You're using memory-mapped files backed by RAM, rather
than actual files, to share some memory space? How are you synchronizing
access between the processes that are sharing this memory?

Paul T.

 
 
 

CE 4.2 and CE 5.0 devices hang if using shared virtual memory during active IO

Post by Vyacheslav » Fri, 22 Dec 2006 18:05:31


I found the reason of the *** . By some yet to be discovered reasons one
of the working threads with ABOVE_NORMAL priority takes all processor
recources. WinCE is an old-flavour OS so all controller just stops
responding.

Interestingly it only happens with using shared memory. We use VirtualAlloc
"feature" descibed by Douglas Boling in MSDN - if requested > 2MB it
allocates virtual addresses from shared region and allows to use all
physical memory. We were able to use more than 200 MB of memory on our CE
device within our 1 (one) process! We have special STL custom allocator
working with STLPort and we overrode operator new/delete in our classes.

Still I need to understand which one of our two worker threads enters such
condition that it hangs. And why this happens only when I use shared memory.
But at least I know what to do.



"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
 
 
 

CE 4.2 and CE 5.0 devices hang if using shared virtual memory during active IO

Post by Bruce Eitm » Fri, 22 Dec 2006 22:50:07

What does ABOVE_NORMAL mean in this context? Priorities are between 0 and
255. I think that it may mean that you are using the macro
THREAD_PRIORITY_ABOVE_NORMAL. If that is so, you must be using
SetThreadPriority and **NOT** CeSetThreadPriority.

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member
 
 
 

CE 4.2 and CE 5.0 devices hang if using shared virtual memory during active IO

Post by Paul G. To » Sat, 23 Dec 2006 01:26:11

If a thread at a high priority is ready to run, then it will get *all* the
time until it either a) is no longer ready to run (it blocks), or b) some
thread with equal or higher priority is ready to run. If that thread is the
highest thread priority in the system, it will run until it's done, starving
every other thread in the system. That's the way it's *supposed* to work.

Paul T.
 
 
 

CE 4.2 and CE 5.0 devices hang if using shared virtual memory during active IO

Post by newbe » Sat, 23 Dec 2006 05:32:44

I agree with Paul. In order to test I wud add some sleep to your
ABOVE_NORMAL thread and see if that improves the state.

On Dec 21, 11:26 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
 
 
 

CE 4.2 and CE 5.0 devices hang if using shared virtual memory during active IO

Post by Vyacheslav » Sat, 23 Dec 2006 16:47:34

I was able to fix the issue. The problem was in the thread sync code of the
publicly available "Doug Lee malloc library" which deadlocked in eternal
loop if the threads beeing synced had different priorities.

This is the incorrect sync code:

#define MLOCK_T long

static int win32_acquire_lock (MLOCK_T *sl) {
for (;;) {
#ifdef InterlockedCompareExchangePointer
if (!InterlockedCompareExchange(sl, 1, 0))
return 0;
#else /* Use older void* version */
if (!InterlockedCompareExchange((void**)sl, (void*)1, (void*)0))
return 0;
#endif /* InterlockedCompareExchangePointer */
Sleep (0);
}
}

static void win32_release_lock (MLOCK_T *sl) {
InterlockedExchange (sl, 0);
}


According to documentation
Sleep (0);
returns remainder of time slice to other threds ONLY if there are threads of
the equal priority.

So the thread with lower priority (3) locked the resource and then the
thread with higher priority (2) was in dead lock.

I am going to test perfoimance loss from switch to CRITICAL_SECTION or
either leave it with CRITICAL_SECTION or use Sleep(somethng > 0);


P.S. I was able to get debugger to work by assigning my GUI thread
BELOW_NORMAL
priority (4) and making other threads to run at normal priority (3). So only
the application itself hanged and not the debugger or OS.





"newbee" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...





 
 
 

CE 4.2 and CE 5.0 devices hang if using shared virtual memory during active IO

Post by Dean Ramsi » Sun, 24 Dec 2006 00:22:26

know this isn't the issue you're chasing, but what function call are you
using to set the thread priorities? If you are using CeSetThreadPriority
with these priority numbers, you're making a mistake. If you are using
SetThreadPriority you're ok, but understand you're actually operating in the
LOWEST 8 priority levels of the system.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Vyacheslav Lanovets" <nobody> wrote in message
news: XXXX@XXXXX.COM ...