Poll: Question for all developers

[Brad Jones]

Thanks for answering honestly.

If you can also say when you first did multithreaded development in a post in this thread, that would be appreciated.

Brad!

[GCDEF]

A little bit. I only use threads when I have to. First time was about 7 years ago I guess.

[TheCPUWizard]

The first "multi-threaded" application I did was actually back in the late 1970's [30 years ago]

It was a realtime dedicated controller which switched tasks based upon interrupts. Since there was NO "operating system" I had to develop all of the code for saving/restoring state, protecting the integrity of shared resources, etc.... Much easier today with built-in scheduling and library/language functions to implement the synchronization/protection...

[cilu]

I can't think of any serious application being single-threaded. So, yes, the answer is of course "yes". What was the first? I'm not very sure, I think I was in the second year in college, that must be around 1999-2000.

[JVene]

It does depend on what you call a thread.

My first work in 'threads' was in Unix, around 1981/2, but at that time it wasn't exactly what we think of as threads. We usually forked processes, used shared memory to communicate between the processes, or we launched processes "in the background".

Probably not a qualifier, but in DOS, from 83 forward, I would use the timer to fire off a background task periodically - a bit like the next entry.

I don't think this qualifies either, but in Win16 3.0 + (when was that, 91 through 95), we used 'OnIdle' to simulate threads. The process was written to work in bursts, then return, saving state in order to pick up and continue on the next OnIdle message.

Then, on OS/2, real threads - probably '94 - with the Borland compiler.

Certainly the moment we could actually write Windows95 'Win32' programs, even with the developer previews in early '95.

I wrote the first 'Queue' objects, representing threads of executing taking callback functions, for my own library in OS/2 around 94/95, along with associated synchronization objects.

I use threads on a whim now because of that.

[TheCPUWizard]

Emphasis added....

I wrote the first 'Queue' objects,

Quite a bold statement JVene....

[Deniz]

I've been doing it for about 6 years. Still learning the tips/tricks to it.

[ovidiucucu]

Quite recently... just since Win32.

[JVene]

TheCPUWizard:

Well, if you didn't account for the clause separation, I can certainly see how that would sound like I was an inventor the technology.

Without the interrupting clause it would read:

I wrote the first 'Queue' objects for my own library......

It's a much smaller claim, I assure you!

[TheCPUWizard]

Thats good to here, I was afraid you might have a petent, and I would have to pay royalities

OTOH: if you could get $0.01 for every instance of every type of queue object in every copy of windows, you would surely be a rich man.

BTW: A conventional Queue is a "FIFO", while a stack (also a type of queue) is a "LIFO". About twenty years ago I developed a multi-parameter dynamic prioriitized queue, and to the best of my knowledge coined the term "SISO" (Sometime In/Sometime Out), actually made it into a number of military reference manuals

[Arjay]

My first multi-threaded app was for an improved version of an automated test harness (which executed application test scripts written with Visual Test). This was around 1995.

The goal of the test harness was to execute the test scripts, record any errors, restore the system to a known good state and keep running scripts. I wanted to be able to fire off thousands of scripts and have them completed by the next morning - it wasn't acceptable to return the next morning to find that the harness got hung up about half way through the test pass.

To get the scripts to continue running, I kept adding features:

• Script timeout checks if the script exceeded its allotted time
• Check for error dialogs. Did the system popup any error dialogs (like out of memory or application exception dialogs).
• Check for whether the application hung (i.e. was the main window of the app 'Not responding').
• Track a list of system processes for cleanup purposes
• Check if the script finished.

The original architecture using the checks (which improved the chance that the test pass would complete) consisted of a windows timer that would trigger every two seconds and perform each of the checks when the timer 'triggered'.

That worked pretty well but then we needed to add more features to the harness which made the timer architecture more and more complicated and less reliable. For example, tests were written that would cause the application to display known 'error' dialogs and we needed a way to delay the harness intercepting these dialogs before the test script could act on it. So we assigned delay values for each type of error dialog to intercept (so now the harness would wait the specified number of seconds before treating the dialog as an error) and allow the test enough time to handle the dialog. I forget exactly how I accomplished this but I recall starting a secondary timer to handle the delay when an error dialog was intercepted, stopping the main timer, letting the delay timer run until the dialog disappeared and then restarting the main timer if it happened. Anyway it wasn't pretty.

When the harness was rearchitected, a thread was used to replaced the windows timer - this thread just waited in a WFSO and woke up every two seconds. There were other threads to check for the error dialogs and hung app conditions. These 'check' threads were mostly sleeping and were awaken with the timer thread triggered. If these secondary threads encountered error conditions, they simply set an event (which indicated the type of error encountered).

The dialog error check thread internally handled the delay requirement earlier and only reported an error when the error dialog remained after the delay value.

You may read all of this and think how could this be simpler than a single threaded app? Well, it was because each secondary thread was responsible for tracking and recording its type of error. The main thread simply triggered these threads and waited on for any error events to be set. Unlike the original timer method, each new check thread was now decoupled from the other checks.

The threading improved the ability to intercept error conditions. Eventually this same test harness architecture would be used to managed tests over 80 machines and multiple Windows OS's. In fact one test pass across all machines executed more the 750,000 test scripts in a 3-day 24/7 period. Clearly in an operation such as this, having a harness that works most of the time isn't going to cut it. Even a 1% harness failure rate (where the harness hung and couldn't continue) would not be acceptable. If I remember correctly, we were at something more like 0.001% - not too shabby really.

[danandu]

Yes, But my first was about 2yrs before.

[humptydumpty]

recently in a Client Server App .Which was based on Bluetooth Communication.
Thanx

[dwurity]

Yes, the First multithreading work was done when I am in 2nd year of my college some where in 2002.

And last time I did it in my previous company for handling multiple connections to a remote machine, i.e., some where around 2004.

Thanx

[VictorN]

Not so late. About 5 or 6 years ago (in about one year after beginning VC++/MFC programming).