News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Help with Opengl Khronos quote

Started by kiptron, October 29, 2020, 09:49:44 AM

Previous topic - Next topic

kiptron

 I run Opengl at the lowest level.  No libraries. I have to figure everything out
for myself. Can one of you pro's tell me what this quote from the Khronos
group means. I think it would help me. "Applications are responsible for
providing the synchronization across API calls when objects are accessed
from different execution threads." I think this would help me get things
working.  Thanks much, Kiptron

TouEnMasm


You can use threads for generate multiple objects on the screen.
Each thread use data who can be shared between  all threads.
It is here there is a problem of synchronisation,a thread could have need of a particular data during a certain time.
If another thread change this data,You could have unpredictable results on the screen.
Fa is a musical note to play with CL

kiptron

Thank you for responding Tou. So how do I do this synchronization ?
                                                        Thanks Kiptron

jj2007

There are quite a number of methods. When you launch a thread, it is kind of a separate program that acts without caring for the main program. One simple method is to let the thread do its work, and before it returns (i.e. it finishes), the thread sends a message to the main program.

MyDownloadThread proc
  ....
  invoke SendMessage, hMainWindow, WM_READY, 123, 456
  ret
MyDownloadThread endp

WndProc ...
  .if uMsg==WM_READY
     print "thread has ended", 13, 10
  .endif

kiptron

Thanks for getting back to me JJ.  I am trying to understand what you posted. In my
case the called thread is an API call inside of the graphics driver so I can't get inside
it to modify the code to issue a sendmessage prior to the return, so I don't really
understand what you are referring to. Do I issue a sendmessage prior to calling
the API function ? When calling an API function(proc) is that a different thread than
my own normal masm project code ? Stay well over there. The last time we spoke
was in February and Covid was running wild back then. De Ja Vu  all over again.!   Kiptron

dedndave

Good to see you folks. :biggrin:
Once you have a handle on what my friend, Jochen, mentioned,
you will find there are two important concepts to grasp to write threaded code:

1) Thread Lock may occur, where one thread endlessly waits for the other to respond
2) Bus Lock is a hardware condition that allows two threads to communicate without simultaneous interference

Ignore the fact that both terms use the word, "Lock".
Totally unrelated - lol

We don't have to teach you about thread lock.
The first time you write locked code and debug it, you will avoid it by yourself.  :badgrin:

Bus Lock is different, we use specific instructions and/or functions to communicate between threads.
Personally, I find the XOR instruction easy.
When used between a register and a memory location,
the bus is naturally locked to prevent interference from another thread.

dedndave

Holy Moly - Jochen has 2,000 more posts than me !!!  :sad:

kiptron

You guys lost me. You mean something like xor qword ptr[rbx], rax  ?  That is a normal instruction
that will zero any common bits in source and destination. Usual stuff. It will not lock any buss that I
know of.  At what point do you run this instruction ? I'm just trying to get API calls to run properly.
                                                                                             Thanks again  Kiptron

jj2007

Quote from: kiptron on October 30, 2020, 12:29:32 PMIn my
case the called thread is an API call inside of the graphics driver so I can't get inside
it to modify the code to issue a sendmessage prior to the return

Can you show us the piece of code where you do that? Just the CreateThread part.

Have you looked at WaitForSingleObject already?

@DednDave: Welcome back, my friend - it's time to catch up  :biggrin: :thup:

TouEnMasm

Hello  dedndave,happy to see you again !
Fa is a musical note to play with CL

Siekmanski

Hi kiptron,
Maybe you can make use of this: "Critical Section Objects"
The critical section of a piece of code is a place where only one thread of execution is allowed to be at a time, to prevent things like race conditions.

https://docs.microsoft.com/en-us/windows/win32/sync/critical-section-objects

Hi Dave, where have you been for so long?   :thumbsup:
Creative coders use backward thinking techniques as a strategy.

kiptron

 Hi guys,  I have not been clear I guess. I have one simple question which needs a yes
or no answer. All of us make API calls all the time. These calls usually go into some dll
somewhere in system memory. I will call that the "called code". Our little masm app. is
the "calling code". Right ? A no-brainer so far.  Is that "called code" a different execution
thread than our masm code which called it.? If not, then my little app is only one thread
and there is no other thread involved and this is not the issue causing instability and
protection faults.   Thanks Kiptron

hutch--

You don't need to worry about system API functions, they reside in memory and are callable without having to bother about if they are threaded or not. If you have not started any new threads apart from your main app, then threading considerations are not needed.

kiptron

  Thank you Hutch, Very clear and simple. Does this apply to an API like Opengl
as well ? I obtain address pointers to the modern calls which are not included in
the original 1991 release of Opengl. Usually programmers rely on higher level
libraries to obtain these addresses but I do it all manually. Stubborn I guess  Kiptron

hutch--

Appreciate that I do very little graphics work apart from images so I am not the right person to ask about the guts of OpenGL but if it is a DLL that gets loaded into memory and has callable functions, its no different to any other DLL that does the same. I don't know what OS version you are using but the assumptions of long ago can come back and bite you when the inner workings of the OS have changed and all you can ever rely on is the published interface for the function you are calling.