Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / DGDK.net Threading problem in my code (I think)

Author
Message
jasuk70
21
Years of Service
User Offline
Joined: 3rd Dec 2002
Location: Hemel Hempstead
Posted: 22nd Aug 2007 01:07
It's late so this may be a "Doh!" incident but...

I've got one thread which for instance I'll call the main thread and another thread which I'll call a worker thread.

The main thread is doing this:



The worker thread is running like this:



There is only one component in the _components collection which is this:



The main thread seems to be running round its loop with no issues.

The worker thread gets to this line in the button object and runs the ImagePaste sub:

ImagePaste(Zone.X, Zone.Y, ButtonUpImageID)

The ImagePaste code is:



The thread seems to stop at:

oDBImage.PasteImage(image.ImageID, x, y)

and will not continue.

But strangely enough, If I change the main thread by adding a Sync()

Public Sub Sync()
SyncLock oDBCore
oDBCore.Sync()
End SyncLock
End Sub

to:



The paste unlocks during the sync.

Anyone have any ideas about this?

Cheers,

Jas

----
"What is this talk of 'release'? Klingons do not'release' software. It escapes leaving a bloody trail of developers and quality assurance people in its wake!"
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Sep 2007 04:27
Yup - only a theory - but the device "Context" is hitting a "critical section" because multiple threads can't manipulate the same display "context" (Essesntially the driver to the video ram for the display you are controlling). By critical - the wording means that "I need to do something to this memory - EVERYONE ELSE WAIT Until I am done" (this is what I think is hanging your other thread.)

cypher0
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location:
Posted: 10th Sep 2007 03:12
I think that would be about right - threads are independant and have no idea about each other's memory space*, one thread should not mess with the memory of another one (as it doesn't know what it's being used for or if it's moving around). Your main thread has been assigned the graphics memory and the worker thread has not.

Saying that, you can get your worker thread to access the memory space of the main thread by providing a delegate (in VB type 'delegate' and press F1 for a good tutorial) or using a volatile pointer - look up the C++ keyword 'volatile'. VB can also use this via System.Threading.Thread.VolatileRead and System.Threading.Thread.VolatileWrite.

You could also just put everything in one thread.

*I'm not entirely sure about managed languages here.
jasuk70
21
Years of Service
User Offline
Joined: 3rd Dec 2002
Location: Hemel Hempstead
Posted: 10th Sep 2007 11:43
It's ok, I've solved all my thread issues. Everything I do is thread safe, but behind the code in the DGDK, it's another matter. I got round the problem by changing where I put the sync.

.net 2.0 will error if you try to do thread unsafe things (Or the VB Compiler will anyhow)

Jas

----
"What is this talk of 'release'? Klingons do not'release' software. It escapes leaving a bloody trail of developers and quality assurance people in its wake!"
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 11th Sep 2007 01:29
Bummer - half of my successful "way fast" Multi-threading solutions are considered "unsafe" - .Net wouldn't let me then! (I prefer my own syncing methods so I know what's going on versus relying on some other dude's mutex or "critical section" code. It's actually pretty simply once you wrap your head around why contentions and bombs can go off. the hard part is making the code shared by the two "threads" be designed to be threadable so they don't stomp where you didn't suspect!)

Login to post a reply

Server time is: 2024-10-08 22:24:33
Your offset time is: 2024-10-08 22:24:33