Home > Archive > Smartphone Developer Forum > October 2005 > something about GDI/dc synchronization
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
something about GDI/dc synchronization
|
|
|
| If there has two threads in my app.
thread 1 draw text, and thread 2 fill rect.
Take example above:
DWORD Thread1(void * lp)
{
hDC = GetDC(NULL);
... // draw dc
Release(NULL, hDC);
}
No synchronization taken with these two threads, they just running till
exit.
Can they cause deak-lock.
Any one can give more about internal synchronization protection by OS API
calling.
such as : A draw somthing at part of a window, B also draw something at part
of the same window.
Does windows lock special region or lock entire window?
Regards.
leo
| |
| Gary Daniels [MS] 2005-10-21, 7:04 pm |
| This is a very well tested scenario and deadlocks do not occur.
You need to keep in mind that just the area on the screen is not the only
thing that needs to be protected within GDI. You also need to protect the
handle table and all of the gdi objects. For example, a bitmap object can be
used by any number of threads within a process, what happens if one thread
deletes the bitmap object while the other is using it to draw to the screen?
Without going into implementation details, yes, there are locks within GDI
and you must lock more than a region of the screen or a window to guarantee
reentrency, you must lock all of the GDI shared data. Two threads (or even
two processes) cannot be within the display driver simultaniously.
Gary Daniels
Windows CE Multimedia and Graphics
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
"Leo" <lma@telenav.cn> wrote in message
news:%232zus5i1FHA.904@tk2msftngp13.phx.gbl...
> If there has two threads in my app.
> thread 1 draw text, and thread 2 fill rect.
>
> Take example above:
>
> DWORD Thread1(void * lp)
> {
> hDC = GetDC(NULL);
> ... // draw dc
> Release(NULL, hDC);
> }
>
> No synchronization taken with these two threads, they just running till
> exit.
>
> Can they cause deak-lock.
> Any one can give more about internal synchronization protection by OS API
> calling.
> such as : A draw somthing at part of a window, B also draw something at
> part of the same window.
> Does windows lock special region or lock entire window?
>
> Regards.
>
> leo
>
| |
|
| Oh, many thanks to your detailed explanation.
But I have some question remained. DATA ABORT exception occurred frequently
within our project and I checked all possible code, then I found that some
guys used several threads to drawing one window at the same time with no
sync up or protection.
So I doubt that might the threads causing the exceptions. As I knew,
dead-lock can cause
DATA ABORT exception. But as you mentioned, WINDOWS GDI is designed so well
to prevent
such dead-lock.
Then I removed the threads and moved to drawing code to WNDPROC MSG block
using SendMessage() to call
drawing if needed. Thus, the drawing is sync up at client side. After many
long time testing, I had never
encounterd DATA ABORT again. So I want to know what is the key factor? Does
GDI in WINCE differ from WIN32 within
the SHARE-DATA protection?
I my opnion, I will make sync up in my client code and I don't guarantee the
WINDOWS do the thing internal.
But some guys in our team don't agree this.
"Gary Daniels [MS]" <garydan@online.microsoft.com> wrote in message
news:%23B3aTjo1FHA.3300@TK2MSFTNGP15.phx.gbl...
> This is a very well tested scenario and deadlocks do not occur.
>
> You need to keep in mind that just the area on the screen is not the only
> thing that needs to be protected within GDI. You also need to protect the
> handle table and all of the gdi objects. For example, a bitmap object can
> be used by any number of threads within a process, what happens if one
> thread deletes the bitmap object while the other is using it to draw to
> the screen? Without going into implementation details, yes, there are
> locks within GDI and you must lock more than a region of the screen or a
> window to guarantee reentrency, you must lock all of the GDI shared data.
> Two threads (or even two processes) cannot be within the display driver
> simultaniously.
>
> Gary Daniels
> Windows CE Multimedia and Graphics
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> You assume all risk for your use.
>
| |
| Gary Daniels [MS] 2005-10-24, 7:02 pm |
| Was the exceptions you were seeing in your application space, or in GWES?
Windows CE and WIN32 are very different in their architecture. For the
desktop GDI lives in the user's memory space and calls are batched and
executed by the display driver in kernel space, i don't know the exact
detail of how the batching works, but i do know that if you tell the desktop
GDI to do somthing bad, like create a DIB from a bogus pointer and then use
it, then the exception will be in the user space.
For Windows CE all of GDI lives in the kernel memory space within GWES.exe,
so if you were to deadlock GDI on CE or somehow trigger an unhandled
exception within GDI, then it could bring down the whole gdi and display
system for the whole system, not just your application. If the exception you
were seeing was a GWES exception, then you may have been hitting some sort
of error case where multiple threads causes something bad to happen within
GDI. If the exception occured in your process space, then your threads were
doing something wrong with their shared data. Also, if the exception happens
within the GWES process space, then it won't be propagated to your
application, it'll be handled by the GWES exception handler and your GDI
call will fail, not except, it won't result in your application being
terminated from an unhandled exception.
Gary Daniels
Windows CE Multimedia and Graphics
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
"Leo" <lma@telenav.cn> wrote in message
news:ObKlDu51FHA.3660@TK2MSFTNGP15.phx.gbl...
> Oh, many thanks to your detailed explanation.
>
> But I have some question remained. DATA ABORT exception occurred
> frequently
> within our project and I checked all possible code, then I found that some
> guys used several threads to drawing one window at the same time with no
> sync up or protection.
>
> So I doubt that might the threads causing the exceptions. As I knew,
> dead-lock can cause
> DATA ABORT exception. But as you mentioned, WINDOWS GDI is designed so
> well to prevent
> such dead-lock.
>
> Then I removed the threads and moved to drawing code to WNDPROC MSG block
> using SendMessage() to call
> drawing if needed. Thus, the drawing is sync up at client side. After many
> long time testing, I had never
> encounterd DATA ABORT again. So I want to know what is the key factor?
> Does GDI in WINCE differ from WIN32 within
> the SHARE-DATA protection?
>
> I my opnion, I will make sync up in my client code and I don't guarantee
> the WINDOWS do the thing internal.
> But some guys in our team don't agree this.
>
>
> "Gary Daniels [MS]" <garydan@online.microsoft.com> wrote in message
> news:%23B3aTjo1FHA.3300@TK2MSFTNGP15.phx.gbl...
>
>
| |
|
| Great!
Thanks for your kindless and patience.
leo
"Gary Daniels [MS]" <garydan@online.microsoft.com> wrote in message
news:%238blJPO2FHA.3136@TK2MSFTNGP09.phx.gbl...
> Was the exceptions you were seeing in your application space, or in GWES?
>
> Windows CE and WIN32 are very different in their architecture. For the
> desktop GDI lives in the user's memory space and calls are batched and
> executed by the display driver in kernel space, i don't know the exact
> detail of how the batching works, but i do know that if you tell the
> desktop GDI to do somthing bad, like create a DIB from a bogus pointer and
> then use it, then the exception will be in the user space.
>
> For Windows CE all of GDI lives in the kernel memory space within
> GWES.exe, so if you were to deadlock GDI on CE or somehow trigger an
> unhandled exception within GDI, then it could bring down the whole gdi and
> display system for the whole system, not just your application. If the
> exception you were seeing was a GWES exception, then you may have been
> hitting some sort of error case where multiple threads causes something
> bad to happen within GDI. If the exception occured in your process space,
> then your threads were doing something wrong with their shared data. Also,
> if the exception happens within the GWES process space, then it won't be
> propagated to your application, it'll be handled by the GWES exception
> handler and your GDI call will fail, not except, it won't result in your
> application being terminated from an unhandled exception.
>
> Gary Daniels
> Windows CE Multimedia and Graphics
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> You assume all risk for your use.
>
>
>
> "Leo" <lma@telenav.cn> wrote in message
> news:ObKlDu51FHA.3660@TK2MSFTNGP15.phx.gbl...
>
>
|
|
|
|
|