Help with Opengl Khronos quote

[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.

[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.

Code Select Expand

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.
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. 

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 !!! 

[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]

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

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 

[TouEnMasm]

Hello  dedndave,happy to see you again !

[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?   

[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.