Jump to content

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Find out more here. X
X


Photo

Threads or some form of parallelism


  • This topic is locked This topic is locked
34 replies to this topic

#21 Nutster

Nutster

    Developer at Large

  • Developers
  • 1,450 posts

Posted 19 July 2005 - 06:30 PM

Just to wade in again and try to clarify a few ideas that Valik touched on.

Making a program multi-threaded or single-threaded is an "initial design-time" decision, not a "add it on at the end" prospect. The initial design of the program must be made with multi-threading in mind in order to optimize the implementation, or in the case of AutoIt's internals as they stand, allow it in anything resembling a reasonable resource load. Several decisions that Jon, and later the rest of the development team, made during the initial creation of AutoIt 3 (That is around 3.0.0) would have to have been made differently. At this stage of the game, it would be a nightmare to re-write and test such a major departure from the current abilities of the system.

There are only a few cases where multi-threading makes sense. The most common one involves several processors to share the program over and a process that can be defined using (hopefully) one function with different arguments that complete the processing on its own. One such task like this is to run database engines (where several users send requests to one program which then assigns the individual requests to seperate threads), or the computation of a non-interdependent mathematics model. These are really not the kind of tasks that AutoIt was designed for, even though it is becoming much more than an automation engine.

I would like to see some multi-threading (real or simulated) capability in AutoIt, but at this late stage of the game, it is just too much work to change it over. When it comes time for us to design V4, I will be pushing for this idea along several others.

Well that's my three cents worth (2 American).

David Nuttall

Nuttall Computer Consulting

An Aquarius born during the Age of Aquarius
AutoIt allows me to re-invent the wheel so much faster.

I'm off to write a wizard, a wonderful wizard of odd...








#22 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 19 July 2005 - 06:51 PM

I pretty much agree with everything David has said and will add this to boot. For most (all?) of us, this is our first attempt to design and shape a language. Also, though this is Jon's (at least) 2nd attempt, he never imagined the scope or popularity AutoIt would achieve (None of us did). Therefore, design decisions were made as they were for a number of factors including simple mis-judgments on our part being new to the whole language design thing. Given an opportunity to do all over again, a second implementation would be significantly superior, as is the case with all projects. Anybody reading this right now doing any development, even with AutoIt should know that the first implementation of something is always the worst. But the key thing is, we didn't screw up so bad that the result is a fundamentally flawed language. We don't feel that AutoIt 3 has any significant problems that would warrant a rewrite nor do we feel that its reached its pinnacle and its time to move on and replace it. Development continues on as healthy as ever right now. Even Jon has gotten back into things with outstanding new ideas that none of the rest of us have thought up (Although he screwed up there, once he opened his big mouth I have 9328958342 ideas feeding off his one simple one, :) ). AutoIt has grown in scope beyond a simple automation language to a full-fledged scripting language and has exceeded both the original goals and the original scope. Quite honestly, we're all probably lucky its as good as it is given just how much we under-anticipated all of that.

#23 VicTT

VicTT

    Universalist

  • Active Members
  • PipPipPipPipPipPip
  • 379 posts

Posted 23 July 2005 - 10:33 AM

Alright..If it's a possible prospect for the future(V4), I can't wait to see it..BTW, Valik..Speed is not that much of a problem nowadays..there is no sense in coding apps that need to be run at compiled language speed..That's not the scope of AutoIt either..But I agree with what you've said..in the end, it's more feasible to wait than "hack a thread()" :)..Thanks for caring..

Together we might liveDivided we must fall


#24 Nutster

Nutster

    Developer at Large

  • Developers
  • 1,450 posts

Posted 27 July 2005 - 11:57 PM

Alright..If it's a possible prospect for the future(V4), I can't wait to see it.

<{POST_SNAPBACK}>

Can't wait to see it? You will have to. We are not ready to start writing it yet. Sorry.

David Nuttall

Nuttall Computer Consulting

An Aquarius born during the Age of Aquarius
AutoIt allows me to re-invent the wheel so much faster.

I'm off to write a wizard, a wonderful wizard of odd...


#25 WSCPorts

WSCPorts

    Adventurer

  • Active Members
  • PipPip
  • 148 posts

Posted 15 August 2005 - 06:20 PM

@Wooter : so with the implementation being single threaded... as overly stated by all so when a script is active and then waits in while loop the thread must be suspended running the loop then the thing is to reopen the thread alloc some memory write stuff then callback to the origanal process..

Provided below is SDK documentation of singlethreaded apartments
and a Overveiw of processes, threads and apartments

Single-Threaded Apartments

Using single-threaded apartments (the apartment model process) offers a message-based paradigm for dealing with multiple objects running concurrently. It enables you to write more efficient code by allowing a thread, while it waits for some time-consuming operation to complete, to allow another thread to be executed.

Each thread in a process that is initialized as an apartment model process, and that retrieves and dispatches window messages, is a single-threaded apartment thread. Each thread lives within its own apartment. Within an apartment, interface pointers can be passed without marshaling, and therefore, all objects in one single-threaded apartment thread communicate directly.

A logical grouping of related objects that all execute on the same thread, and therefore must have synchronous execution, could live on the same single-threaded apartment thread. However, an apartment model object cannot reside on more than one thread. Calls to objects in other processes must be made within the context of the owning process, so distributed COM switches threads for you automatically when you call on a proxy.

The interprocess and interthread models are similar. When it is necessary to pass an interface pointer to an object in another apartment (on another thread) within the same process, you use the same marshaling model that objects in different processes use to pass pointers across process boundaries. By getting a pointer to the standard marshaling object, you can marshal interface pointers across thread boundaries (between apartments) in the same way you do between processes. (Interface pointers must be marshaled when passed between apartments.)

Rules for single-threaded apartments are simple, but it is important to follow them carefully:

Every object should live on only one thread (within a single-threaded apartment).


Initialize the COM library for each thread.


Marshal all pointers to objects when passing them between apartments.


Each single-threaded apartment must have a message loop to handle calls from other processes and apartments within the same process. Single-threaded apartments without objects (client only) also need a message loop to dispatch broadcast sendmessages that some applications use.


DLL-based or in-process objects do not call the COM initialization functions; instead, they register their threading model with the ThreadingModel named-value under the InprocServer32 key in the registry. Apartment-aware objects must also write DLL entry points carefully. There are special considerations that apply to threading in-process servers. For more information, see In-Process Server Threading Issues.


While multiple objects can live on a single thread, no apartment model object can live on more than one thread.

Each thread of a client process or out-of-process server must call or call CoInitializeEx and specify COINIT_APARTMENTTHREADED for the dwCoInit parameter. The main apartment is the thread that calls CoInitializeEx first. For information on in-process servers, refer to In-Process Server Threading Issues.

All calls to an object must be made on its thread (within its apartment). It is forbidden to call an object directly from another thread; using objects in this free-threaded manner could cause problems for applications. The implication of this rule is that all pointers to objects must be marshaled when passed between apartments. COM provides the following two functions for this purpose:

CoMarshalInterThreadInterfaceInStream marshals an interface into a stream object that is returned to the caller.


CoGetInterfaceAndReleaseStream unmarshals an interface pointer from a stream object and releases it.


These functions wrap calls to CoMarshalInterface and CoUnmarshalInterface functions, which require the use of the MSHCTX_INPROC flag.

In general, the marshaling is accomplished automatically by COM. For example, when passing an interface pointer as a parameter in a method call on a proxy to an object in another apartment, or when calling CoCreateInstance, COM does the marshaling automatically. However, in some special cases, where the application writer is passing interface pointers between apartments without using the normal COM mechanisms, the writer must handle the marshaling manually.

If one apartment (Apartment 1) in a process has an interface pointer and another apartment (Apartment 2) requires its use, Apartment 1 must call CoMarshalInterThreadInterfaceInStream to marshal the interface. The stream that is created by this function is thread-safe and must be stored in a variable that is accessible by Apartment 2. Apartment 2 must pass this stream to CoGetInterfaceAndReleaseStream to unmarshal the interface and will get back a pointer to a proxy through which it can access the interface. The main apartment must remain alive until the client has completed all COM work (because some in-process objects are loaded in the main apartment, as described in In-Process Server Threading Issues). After one object has been passed between threads in this manner, it is very easy to pass interface pointers as parameters. That way, distributed COM does the marshaling and thread switching for the application.

To handle calls from other processes and apartments within the same process, each single-threaded apartment must have a message loop. This means that the thread's work function must have a GetMessage/DispatchMessage loop. If other synchronization primitives are being used to communicate between threads, the Win32 function MsgWaitForMultipleObjects can be used to wait both for messages and for thread synchronization events. The Platform SDK documentation for this function has an example of this sort of combination loop.

COM creates a hidden window using the Windows class "OleMainThreadWndClass" in each single-threaded apartment. A call to an object is received as a window message to this hidden window. When the object's apartment retrieves and dispatches the message, the hidden window will receive it. The window procedure will then call the corresponding interface method of the object.

When multiple clients call an object, the calls are queued in the message queue and the object will receive a call each time its apartment retrieves and dispatches messages. Because the calls are synchronized by COM and the calls are always delivered by the thread that belongs to the object's apartment, the object's interface implementations need not provide synchronization. Single-threaded apartments can implement IMessageFilter to permit them to cancel calls or receive window messages when necessary.

The object can be reentered if one of its interface method implementations retrieves and dispatches messages or makes an ORPC call to another thread, thereby causing another call to be delivered to the object (by the same apartment). OLE does not prevent reentrancy on the same thread, but it can help provide thread safety. This is identical to the way in which a window procedure can be reentered if it retrieves and dispatches messages while processing a message. However, calling an out-of-process single-threaded apartment server that calls another single-threaded apartment server will allow the first server to be reentered.


Single-Threaded Apartments

Using single-threaded apartments (the apartment model process) offers a message-based paradigm for dealing with multiple objects running concurrently. It enables you to write more efficient code by allowing a thread, while it waits for some time-consuming operation to complete, to allow another thread to be executed.

Each thread in a process that is initialized as an apartment model process, and that retrieves and dispatches window messages, is a single-threaded apartment thread. Each thread lives within its own apartment. Within an apartment, interface pointers can be passed without marshaling, and therefore, all objects in one single-threaded apartment thread communicate directly.

A logical grouping of related objects that all execute on the same thread, and therefore must have synchronous execution, could live on the same single-threaded apartment thread. However, an apartment model object cannot reside on more than one thread. Calls to objects in other processes must be made within the context of the owning process, so distributed COM switches threads for you automatically when you call on a proxy.

The interprocess and interthread models are similar. When it is necessary to pass an interface pointer to an object in another apartment (on another thread) within the same process, you use the same marshaling model that objects in different processes use to pass pointers across process boundaries. By getting a pointer to the standard marshaling object, you can marshal interface pointers across thread boundaries (between apartments) in the same way you do between processes. (Interface pointers must be marshaled when passed between apartments.)

Rules for single-threaded apartments are simple, but it is important to follow them carefully:

Every object should live on only one thread (within a single-threaded apartment).


Initialize the COM library for each thread.


Marshal all pointers to objects when passing them between apartments.


Each single-threaded apartment must have a message loop to handle calls from other processes and apartments within the same process. Single-threaded apartments without objects (client only) also need a message loop to dispatch broadcast sendmessages that some applications use.


DLL-based or in-process objects do not call the COM initialization functions; instead, they register their threading model with the ThreadingModel named-value under the InprocServer32 key in the registry. Apartment-aware objects must also write DLL entry points carefully. There are special considerations that apply to threading in-process servers. For more information, see In-Process Server Threading Issues.


While multiple objects can live on a single thread, no apartment model object can live on more than one thread.

Each thread of a client process or out-of-process server must call or call CoInitializeEx and specify COINIT_APARTMENTTHREADED for the dwCoInit parameter. The main apartment is the thread that calls CoInitializeEx first. For information on in-process servers, refer to In-Process Server Threading Issues.

All calls to an object must be made on its thread (within its apartment). It is forbidden to call an object directly from another thread; using objects in this free-threaded manner could cause problems for applications. The implication of this rule is that all pointers to objects must be marshaled when passed between apartments. COM provides the following two functions for this purpose:

CoMarshalInterThreadInterfaceInStream marshals an interface into a stream object that is returned to the caller.


CoGetInterfaceAndReleaseStream unmarshals an interface pointer from a stream object and releases it.


These functions wrap calls to CoMarshalInterface and CoUnmarshalInterface functions, which require the use of the MSHCTX_INPROC flag.

In general, the marshaling is accomplished automatically by COM. For example, when passing an interface pointer as a parameter in a method call on a proxy to an object in another apartment, or when calling CoCreateInstance, COM does the marshaling automatically. However, in some special cases, where the application writer is passing interface pointers between apartments without using the normal COM mechanisms, the writer must handle the marshaling manually.

If one apartment (Apartment 1) in a process has an interface pointer and another apartment (Apartment 2) requires its use, Apartment 1 must call CoMarshalInterThreadInterfaceInStream to marshal the interface. The stream that is created by this function is thread-safe and must be stored in a variable that is accessible by Apartment 2. Apartment 2 must pass this stream to CoGetInterfaceAndReleaseStream to unmarshal the interface and will get back a pointer to a proxy through which it can access the interface. The main apartment must remain alive until the client has completed all COM work (because some in-process objects are loaded in the main apartment, as described in In-Process Server Threading Issues). After one object has been passed between threads in this manner, it is very easy to pass interface pointers as parameters. That way, distributed COM does the marshaling and thread switching for the application.

To handle calls from other processes and apartments within the same process, each single-threaded apartment must have a message loop. This means that the thread's work function must have a GetMessage/DispatchMessage loop. If other synchronization primitives are being used to communicate between threads, the Win32 function MsgWaitForMultipleObjects can be used to wait both for messages and for thread synchronization events. The Platform SDK documentation for this function has an example of this sort of combination loop.

COM creates a hidden window using the Windows class "OleMainThreadWndClass" in each single-threaded apartment. A call to an object is received as a window message to this hidden window. When the object's apartment retrieves and dispatches the message, the hidden window will receive it. The window procedure will then call the corresponding interface method of the object.

When multiple clients call an object, the calls are queued in the message queue and the object will receive a call each time its apartment retrieves and dispatches messages. Because the calls are synchronized by COM and the calls are always delivered by the thread that belongs to the object's apartment, the object's interface implementations need not provide synchronization. Single-threaded apartments can implement IMessageFilter to permit them to cancel calls or receive window messages when necessary.

The object can be reentered if one of its interface method implementations retrieves and dispatches messages or makes an ORPC call to another thread, thereby causing another call to be delivered to the object (by the same apartment). OLE does not prevent reentrancy on the same thread, but it can help provide thread safety. This is identical to the way in which a window procedure can be reentered if it retrieves and dispatches messages while processing a message. However, calling an out-of-process single-threaded apartment server that calls another single-threaded apartment server will allow the first server to be reentered.


Send comments about this topic to Microsoft.
Copyright © 2005 Microsoft Corporation. All rights reserved.

Edited by WSCPorts, 16 August 2005 - 01:12 AM.

http://www.myclanhosting.com/defiasVisit Join and contribute to a soon to be leader in Custumized tools development in [C# .Net 1.1 ~ 2.0/C/C++/MFC/AutoIt3/Masm32]

#26 Frozenyam

Frozenyam

    Wayfarer

  • Active Members
  • Pip
  • 67 posts

Posted 21 August 2005 - 07:11 AM

First things first... I just want to say that all of the developers are doing an awesome job and I look forward to trying out each beta version as it's released.

A fresher thought I guess. A few of you developers have stated that the current AutoIt would need to be re-written to incorporate multi-threading. You have also mentioned that there were a few things you would do differently if you were to start over. Would it be possible to have a developer maybe do a bit of planning for a second AutoIt if they have time or are tired of looking through the current code? Maybe just some paper planning, and not anything scripted. At least that way, when you later decide the current AutoIt has reached it's peak that there will be a startig point.

I believe that you guys are correct that multithreading is not necessary for the greater majority of the programmers we end up with in the support forums, but as someone who works with simultaneous video and audio transcoding, it would be nice to, IN LATER THE FUTURE, see some support for multithreading. EVEN if it is in the next creation of AutoIt.

Your language, your choice, right?

I'm just suggesting that you bring this AutoIt to it's peak and then possibly think about a multithreaded platform. Like you said, the first version is always the worst. I just hope to see you guys always improving on AutoIt, with... or WITHOUT multithreading.

All of the developers working on this project are doing an awesome job.

Thanks for a great scripting language. :whistle:
"... and the Lord said to John, "Come forth and ye shall receive eternal life," but instead John came fifth and won a toaster."

#27 Nutster

Nutster

    Developer at Large

  • Developers
  • 1,450 posts

Posted 22 August 2005 - 03:24 AM

Would it be possible to have a developer maybe do a bit of planning for a second AutoIt if they have time or are tired of looking through the current code? Maybe just some paper planning, and not anything scripted. At least that way, when you later decide the current AutoIt has reached it's peak that there will be a startig point.

<{POST_SNAPBACK}>

I think all of us are doing this independantly. Every time we think, "I would like it do this. Now, how to do it? Nuts, I would need to make these fundamental changes, which would break too much to be practical. Ok, it goes on my Version 4 wish list."

I have no idea when the current version will reach its peak, but it is probably quite some time off yet. As things slow down on Version 3, you can be sure we will start talking about version 4 with increasing regularity, but that time is not now.

David Nuttall

Nuttall Computer Consulting

An Aquarius born during the Age of Aquarius
AutoIt allows me to re-invent the wheel so much faster.

I'm off to write a wizard, a wonderful wizard of odd...


#28 neogia

neogia

    Universalist

  • Active Members
  • PipPipPipPipPip
  • 269 posts

Posted 23 March 2006 - 08:16 PM

maby a command like Thread($function)

Here's my stab at something about as similar to w0uter's idea as you're going to get. I think it does pretty well though.
My UDFsCoroutine Multithreading UDF LibraryStringRegExp GuideRandom EncryptorArrayToDisplayString"The Brain, expecting disaster, fails to find the obvious solution." -- neogia

#29 nfwu

nfwu

    I'm not active on these forums

  • Active Members
  • PipPipPipPipPipPip
  • 1,234 posts

Posted 24 March 2006 - 09:38 AM

My experience in multi-threading:
A java 3d graphics engine which I created, had a thread for each object. 1 thread for each game object, 1 for each input manager, 1 of each display manager, etc...
Didn't work out too well, I had a LOT of tears appearingon the screen due to objects updating their positions while they were being drawn on the screen, and not to mention, the thread-deadlock now and then.
So I scraped that idea and ended up with a 2 thread solution: 1 for the Input Manager, and another for everything else.
Worked perfectly! Almost no screw-ups except for those bugs which did not involve multi-threading.

So I have implemented this 2-threaded system in my 3d library for AutoIt. A 'master' exe calling up a 'sub' exe, with the 'sub' passing out data through it's stdout stream

Just making the point that the fewer the threads, the easier to debug.

And, i think additional features should be ranked acording to importance, with lesser amount of code needed to change a priority over the populatity of the feature.

#)

#30 Nuffilein805

Nuffilein805

    still posting

  • Active Members
  • PipPipPipPipPipPip
  • 606 posts

Posted 24 March 2006 - 10:57 AM

i did "multithreaded" (more scripts in 1 :)) applications using a hidden window like some ms-progs do to handle the return-values, works fine
but i don't think you really need it if you don't have more than 1 processor (because 100% is the maximum you can get from 1 :mellow:)
i'd like to see this feature, but for now i don't need it

#31 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 24 March 2006 - 06:01 PM

i did "multithreaded" (more scripts in 1 :) ) applications using a hidden window like some ms-progs do to handle the return-values, works fine
but i don't think you really need it if you don't have more than 1 processor (because 100% is the maximum you can get from 1 :mellow: )
i'd like to see this feature, but for now i don't need it

There are lots of reasons to have multi-threaded applications on single processor systems. The benefit of threading comes not from a performance boost of having two threads run in parallel but rather in ease of coding. Take for instance a GUI which downloads a file. You obviously want the UI to still be active while the file is downloading so in order to write it single-threaded, you would have to use asynchronous download calls and download in small chunks to keep the UI snappy. Using two threads, a worker thread can handle the download leaving the main thread free for the UI. The single-threaded method would take quite a lot more code and be a lot harder to maintain than the multi-threaded version. With enough skill, a person could write both versions and it would look identical to the end-user but underneath one method is dramatically simpler than the other to both implement and maintain.

For the record, all programs can be written single-threaded. It is just a matter of skill and desire to write far more complex code to handle all the synchronization necessary for a single-thread to do everything as opposed to allowing the OS to do time-slicing and achieve the same effect.

#32 kuhasu

kuhasu

    Wayfarer

  • Active Members
  • Pip
  • 75 posts

Posted 24 April 2008 - 09:49 AM

There are lots of reasons to have multi-threaded applications on single processor systems. The benefit of threading comes not from a performance boost of having two threads run in parallel but rather in ease of coding. Take for instance a GUI which downloads a file. You obviously want the UI to still be active while the file is downloading so in order to write it single-threaded, you would have to use asynchronous download calls and download in small chunks to keep the UI snappy. Using two threads, a worker thread can handle the download leaving the main thread free for the UI. The single-threaded method would take quite a lot more code and be a lot harder to maintain than the multi-threaded version. With enough skill, a person could write both versions and it would look identical to the end-user but underneath one method is dramatically simpler than the other to both implement and maintain.

For the record, all programs can be written single-threaded. It is just a matter of skill and desire to write far more complex code to handle all the synchronization necessary for a single-thread to do everything as opposed to allowing the OS to do time-slicing and achieve the same effect.



Well,I think multi-threading is very useful especially for data processing.

So I hope there is a Thread() function .

#33 AdmiralClaws

AdmiralClaws

    Where is the fish?

  • Active Members
  • PipPipPipPipPipPip
  • 4,686 posts

Posted 24 April 2008 - 09:57 AM

Well,I think multi-threading is very useful especially for data processing.

So I hope there is a Thread() function .

Sorry to destroy your hopes pal but there is no such function, you could easily have checked that yourself by opening the helpfile and used the search :D

#34 GEOSoft

GEOSoft

    Sure I'm senile. What's your excuse?

  • MVPs
  • 10,573 posts

Posted 24 April 2008 - 12:33 PM

Well,I think multi-threading is very useful especially for data processing.

So I hope there is a Thread() function .

Quote from
The AutoIt NOT to do list.

Multi-threading: It's too late to do this now. The changes required to AutoIt are too great. AutoIt was never intended to be multi-threaded. Writing a multi-threaded application requires an entirely different mindset when writing a program. We did not start with that mindset and trying to retrofit something as significant as multi-threading onto the existing code base is not worth the time or effort. It would be far more beneficial to re-write AutoIt and add in multi-threading that way. That, however, is not planned and is a massive undertaking.

Which means that AutoIt3 is not, and will never be, multi-threading. The soonest that would ever be considered again would be when a new AutoIt core is written.
GeorgeQuestion about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.*** The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else."Old age and treachery will always overcome youth and skill!"

#35 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 24 April 2008 - 04:51 PM

Threads 2 years old in an unused forum... locked.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users