Simplified multi threading demo.

[hutch--]

Multithreading is nothing new in win32 but it is starting to become increasingly relevant with the next generation of multicore processors which can properly run parallel operations in different cores. With basic comprehension the assembler programmer can properly exploit this capacity to produce higher performance apps that divide certain types of tasks into parts that can be processed in parallel.

This demo is intentionally written in a simple manner using the window system in Windows to simplify communication between the controller and threads created from the first window code.

This area of programming can be a lot more complex when there is a need for coordinating different asynchronous threads that may be working in parallel on a sequential block of data with things like signalled states but the general idea is that mulithreading is not in itself all that complicated to write.

If any of our more experienced members have the time and are familiar with some of the more complex aspects of multi-thread coding it would certainly be appreciated fi they posted any of the simpler code they had available.

[attachment deleted by admin]

[EduardoS]

How about a Multithreaded XML parser?

Let's have fun with something a bit more dificult with more than one thread for parsing a single XML  :toothy

[Ghirai]

Thanks for the example hutch.

I might add that i've used critical sections in multithreaded applications to sync various things, and it seems to work great.

[hutch--]

Ghirai,

Thanks for the suggestion, I know basically what they do but have never bothered to test them as I tend to do some of these things in old fashioned ways. Do you remember the task you used it for and the logic you used with it ?

EduardoS,

I may be short on imagination here but why would you multithread an XML parser ?

[EduardoS]

hutch,

1) For parsing a 100MB XML file faster...
2) Just for fun. Have you ever tryed to multithread a sequential task like a XSLT processor or javascript interpreter?

[u]

A bit more advanced, but necessary right from the start.
an article of mine: http://www.codeproject.com/useritems/FastReadWriteLock.asp
(do read the comments after the article!)

The other basic necessary structures are critical-sections (or simple cmpxchg-based locks) and FIFO command-queues.

Making a fast multithreaded XML parser is futile. The format is extremely uncomfortable. Unlike IFF-based binary formats. To split the work between several cpus, one of them first has to do a lot of work. And take into account that you'll be dynamically allocating all the time from both threads. This will mean a 10x or much more speed decrease, imho.
Multithreading is done when work can be easily split between the cpus:
Raytracing: each cpu computes a part of the screen, this can be done independently
Games/multimedia: one cpu works on video, another on audio, another on physics, another on networks.

[hutch--]

Interesting article, any chance of attaching it here as the link requires that you are logged in to download it.

The next highly simplified example addresses using a stack based structure to pass multiple arguments to a new thread that waits for the new thread to read its arguments into local variables before the calling thread exits the calling procedure. This example uses a global flag to perform thsi task and while it seems to work fine, it may not be "politically correct" under current versions of Windows.

[attachment deleted by admin]

[u]

I had forgotten about the logged-in problem, sorry  :red
The UpgradeToWriter() proc is buggy - needs a complete restructuring of the lib, so avoid it.

[attachment deleted by admin]

[EduardoS]

Making a fast multithreaded XML parser is futile. The format is extremely uncomfortable. Unlike IFF-based binary formats. To split the work between several cpus, one of them first has to do a lot of work. And take into account that you'll be dynamically allocating all the time from both threads. This will mean a 10x or much more speed decrease, imho.

Sounds challenging, doesn't it?
A thread can start at the first the byte, a second one at the last, a third and forth at the middle each in one direction and aware they could be reading a comment (so a bit especulative), some checks should be performed from time to time, but not too ofen to avoid the long cache to cache latency, and at the end join the result of all threads, the hierarchical nature of XML make the join part "not so dificult".

[hutch--]

EduardoS,

I was actually more interested in practical multi-threading code rather than speculative ideas that would be at best very hard to achieve and run the risk of not working properly. Don't let me stop you from undertaking a task of this theoretical design as it may make a good example of multithreading but I wont hold my breath waiting for a result.

[daydreamer]

I have to dig up an example that makes use of lowlevel synchronization such as spinloop and makes use of the new opcode "Pause"
raytracing and games is only a few members that do that, we have a wide range of whats our cup of tea of what we like to code in asm in this community
please don't discourage anyone to not try a multithread approach for the sake of getting skilled/enjoy programming in multithreaded programming due to their particular cup of tea doesnt benefit from multithreading
otherwise we will be only a few skilled to get speed outta assembly programming modern cpus, when a standard cpu will be quadcore with decreased clock freq
I believe with so many skilled nongraphics galores in this forum, there must be some who finds out ways to workarounds these problems Ultrano states and some who finds ways to broaden use of when multithread/mulitcpu approach will benefit

looking forward to see what you can come up with EduardoS

[hutch--]

Magnus,

You are barking up the wrong tree. I posted a couple of very simple examples and asked programmers with enough experience to find their own multithreading code and post bits of it for others to see and use. If you have some multithreading code that is reliable and understandable, tidy it up and post it.

When looking for examples of multithreading code, what I don't need is suggestions for single application projects that fit into the very difficult to impossible range for an individual and while I would be interested to see what EduardoS has in terms of source code, I am not going to hold my breath on a viable multithread XML parser.

Now if you want an increase in the complexity of a multithread example, why stop at something as messy as a multithread XML parser, what about a multithreading operating system that will not only run on multicore processors but across multiple machines with very high speed TCP/IP connections ?

[farrier]

Attached is the latest verion of my work-in-progress.  Using the fasm, it presents a dialog with a Start and Stop button.  When the Start button is pressed, the program creates two threads; one uses DirectSound (DS) to record from the default--or specified--sound card, I specify an iMic USB "sound card" which I use on my notebook; the other is a thread which waits for an Event signal from the DS thread and processes the data collected by the DS thread into an MP3 file.  As presented here, it creates both a .wav file and an .mp3 file so that I can compare the quality.

Both threads use the WaitFor...Object calls to wait for a signal. The DS thread uses a Capture buffer which is twice the size of the data block which lame uses in it's process.  Two Notify events are setup for the capture buffer, half way thru the buffer and at the end of the buffer.  As DS records, when it reaches either notification point, it locks the buffer, copy the captured data, signals the mp3 thread to process this data--using the SetEvent call--unlock the thread and continues.  Besides a time-out event, the DS thread uses 3 objects, 2 for the notification points and one for the stop event.  So this thread uses the WaitForMultipleObjects call

The mp3 thread has to take a few things into consideration.  The DS events don't always give the mp3 routine a nice even block of data that lame expects and the recording can "Wrap around" to include data at the end of the capture buffer, continuing at the beginning of the capture buffer.  So the mp3 routine has to reconstruct and size the data block which is then passed to lame.  The only event the mp3 thread waits for is the signal from the DS thread that data is ready, so it uses tje WaitForSingleObject call.

The code is still a little messy and I'll work on it, but it works.  As is, the compression is 8-10 to 1 compared to the .wav file  Also, IDv3 tags are added to the mp3 file

The lame_enc.dll was downloaded from: http://www.rarewares.org/mp3.html
The dsound.inc includes came from madmatt's post in http://board.flatassembler.net/topic.php?t=3911

That's all for now.

farrier


[attachment deleted by admin]

[Farabi]

Hutch:
My ISP disallow me to download anything from the net. So I cannot see your example.
Is that code like this what you mean?

Code Select Expand


fNewThread proc uses esi edi lpProcAddress:dword
LOCAL ThreadID:dword

invoke CreateThread,NULL,NULL,lpProcAddress,\
NULL,NORMAL_PRIORITY_CLASS,\
ADDR ThreadID
invoke CloseHandle,eax

ret
fNewThread endp