multi-threading using MASM32

[Danesh]

Dear all,

It have been long long time that I have not used MASM32 assembler and I really miss the time that I enjoyed programming in assembly. Now, I would like to refresh my memory and try some stuff that would definitely be useful in my work. I would like to ask if anyone has experienced multi-threading in assembly? I know that there are API routines for these kind of purposes but has anyone done any simple implementation as multi-threaded application using MASM32 that can be used as a guidance? I would appreciate if the code can be shared here or by giving a link.

I am also interested to know if there has been any implementation of LAPACK routines e.g. LU decomposition or Gauss elimination to solve matrix equations Ax=b, using MASM32?

Since it has been long time that I have not posted anything in this forum, so I hope that this post will not violate any rules! And if it does, please forgive my Hutch!  :wink

Regards,

Danesh

[jj2007]

Hi Danesh,
There are no problems with the rules :bg
Just search the forum for CreateThread - it's about 4 pages. You may have to repeat the search if you get less than that - a little bug in the forum software.

[dedndave]

also, search for matrix or matrices
you should find a lot of good SSE routines for that stuff

[qWord]

hi,
when using masm32lib-functions (or corresponding macros), you should take a look at the functions source code to check for thread safety.

qWord

[MichaelW]

A quick search shows that 40 of the 223 source files in masm32\m32lib contain a .data directive, so unless the data is read-only, these procedures are probably not thread-safe.

[dedndave]

you don't have to use one of those functions to create a thread   :bg

[jj2007]

A quick search shows that 40 of the 223 source files in masm32\m32lib contain a .data directive, so unless the data is read-only, these procedures are probably not thread-safe.

Same for the MasmBasic package. But the debate is a bit academic: If you go for multiple threads, it's usually because you need 2 or more cores working hard in parallel on some highly specialised number-crunching tasks. Normally you wouldn't bother with high level routines. And if you really have to, try not to do stupid things such as using Open "O", #1, "MyFile.dat" for all four threads.

[dedndave]

well, in this case, that is true
but threads have other uses, like making functions behave asynchronously

[hutch--]

There is a magic rule, if you are going to write multi-thread code, make it fully re-entrant. Now in practical terms if you need to have data available to all of the called procedures from the beginning of a thread, you create a structure that you simply pass the address of to any called procedure up the call tree so you have much the same effect as global data but limited to the thread that originated the structure.

[Danesh]

Thank you so much everyone for all your valuable tips. Well, my main intention is to start developing just some not very complicated LAPACK or even BLAS routines (BLAS functions are easy and I am sure many people has already done it) for my work. To do that, I wanted to be able to have a multi-thread code which can exploit all available cores on a multi-core system. What I can start without concerning about thread safety is to just start parallelizing the loops like OpenMP does which is very simple.

[qWord]

But the debate is a bit academic

Even if you don't like it, it has practical effects  :wink
(e.g. for GUI's controlling one ore more worker-threads, event based stuff / asynchronous operations (e.g. waiting for a socket), ...)

[jj2007]

But the debate is a bit academic

Even if you don't like it, it has practical effects  :wink
(e.g. for GUI's controlling one ore more worker-threads, event based stuff / asynchronous operations (e.g. waiting for a socket), ...)

qWord,
You are right that situations exist where high level functions should be used with great care. I have added today the option to use a non-immediate for Open and Print #x, as in Open "O", #ThreadNum, Str$("File_%i.dat", ThreadNum), so that obvious conflicts can be avoided. There is still a remote chance that two threads try to access temporary buffers in exactly the same nanosecond - I guess that could be solved with a set of ThreadLock/ThreadWait/ThreadUnlock macros. And of course Hutch is right that sets of global structures are one element of dealing with thread safety.

[qWord]

hi,
the purpose of my provious post wasn't to criticize your macros/library - the answer was/is in context to Danesh's question :P

There is still a remote chance that two threads try to access temporary buffers in exactly the same nanosecond - I guess that could be solved with a set of ThreadLock/ThreadWait/ThreadUnlock macros.

In my SmplMath-macros, if solved this problem by giving the user the option to declare a local buffer:

Code Select Expand

xyz proc ...
LOCAL fSlvTLS()
...
This macro declares a buffer, which has allways the the name. The other macros then check if the buffer is defined (IF[N]DEF): if no buffer is supplied, a global buffer is created and a waring is emitted to the build console. Otherwise the local one is used.