From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f4fd2,2c8b175fe3f63b8c X-Google-Attributes: gidf4fd2,public X-Google-Thread: fac41,2c8b175fe3f63b8c X-Google-Attributes: gidfac41,public X-Google-Thread: 1111a3,2c8b175fe3f63b8c X-Google-Attributes: gid1111a3,public X-Google-Thread: 114809,2c8b175fe3f63b8c X-Google-Attributes: gid114809,public X-Google-Thread: 10dd18,2c8b175fe3f63b8c X-Google-Attributes: gid10dd18,public X-Google-Thread: 103376,2c8b175fe3f63b8c X-Google-Attributes: gid103376,public X-Google-Thread: 1008e3,2c8b175fe3f63b8c X-Google-Attributes: gid1008e3,public From: Alan Lovejoy Subject: Re: Threading questions (for FAQ). Date: 1996/09/17 Message-ID: <323F737A.7EE7@concentric.net> X-Deja-AN: 181451535 references: <51m7kr$9cq@oclc.org> content-type: text/plain; charset=us-ascii organization: Modulation mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.eiffel,comp.lang.lisp,comp.lang.modula3,comp.lang.objective-c,comp.lang.python,comp.lang.smalltalk x-mailer: Mozilla 2.01Gold (Win95; U) Date: 1996-09-17T00:00:00+00:00 List-Id: Sean Walton wrote: > > I am putting together a FAQ for Linux Threads, and I understand that this > language supports threading in some degree. Could anyone please help me > answer the following questions: > > 1. Does this language have language elements to support threading? > 2. What are the language elements? > 3. How are individual threads accessed within the language? > 4. How do you debug threads within this language? > 5. Where are sources of information for further study? Smalltalk-80 has had "thread" support since its inception. Details differ among implementations, and the new draft ANSI standard does not deal with threads at all (just one among many other interesting omissions). That said, I will answer your questions with respect to VisualWorks Smalltalk 2.5.1 (the current version). VisualWorks is the de jure descendant of the original Smalltalk-80. Threads in Smalltalk are implemented by the class Process (I believe this is true of all implementations). In VisualWorks and most (but not all) implementations, a Process is not implemented as a host platform thread, but is realized by facilities of the runtime system ("virtual machine"). Considering that robust support for threads is only now appearing in all the major operating systems (at least on desktop computers), this is not that surprising. In spite of the name "Process," a Smalltalk Process is much more like a thread than what UNIX calls a "process." For example, all Processes in the same session of the program share the same "address space" and global namespace. A process is created from a Context (an execution context). Whatever variables are visible to the Context will be visible in the Process. Typically, Processes are created by sending the message #newProcess to a BlockClosure, which instantiates both a new Process and a new BlockContext (a type of Context) for executing the BlockClosure. The new Process uses the new BlockContext to execute the BlockClosure as a separate thread. Each Smalltalk Process can be in any of the following states: suspended (the initial state), scheduled but waiting to run, running or terminated. Only one process can be running at a time since almost none of the vendors has implemented support for multiple processors (Smalltalk MT is an exception to this, but only because their Processes are based on host OS threads). A suspended or terminated process will not be allowed to run. Sending the message #resume to a suspended process causes it to be scheduled for execution. Which process will actually be selected to run is determined by relative process priority: the system runs the scheduled process with the highest priority. A running process can lose control of the processor 1) by executing its last instruction and exiting (an implicit termination), 2) by being explicitly suspended (which happens if the Process is sent the message #suspend, or may happen if the message #wait is sent to a Semaphore), 3) by being explicitly terminated (which happens if the Process is sent the message #terminate), 4) by being preempted when a higher priority process gets scheduled for execution (which may happen because the current process sends the message #resume to a higher-priority process, because the current process sends the message #signal to a Semaphore, or because the runtime system signals a Semaphore). A preempted Process is still scheduled, not suspended. Control and coordination of Processes is done using instances of class Semaphore, which is an implementation of the standard CS concept of "counting semaphore." Sending the message #signal to a Semaphore increments the signal count if there are no processes suspended (waiting) on the semaphore, otherwise the process waiting on the semaphore with the highest priority is resumed. Sending the message #wait to a Semaphore when the semaphore's signal count is greater than zero simply decrements the count. Otherwise, if the signal count is zero then the current process will be suspended and put on the semaphore's waiting list. There are several system semaphores that are known to the runtime system. These semaphores are signalled when certain events occur, such as user io or clock events. Standard system processes wait on these semaphores, and take appropriate action when they are signalled. Here's a simple example: | process1 process2 semaphore | semaphore := Semaphore new. process1 := [Transcript cr; show: 'Hello, ...'] newProcess. process1 priority: Processor activeProcess priority + 1. process2 := [Transcript show: 'world!'] newProcess. process2 priority: Processor activeProcess priority. process2 resume. "Schedules but does not run process2 (priority not high enough)" process1 resume. "Schedules and runs process1, which immediately waits on a semaphore" semaphore signal."Causes current process to be preempted by process1" (Delay forMilliseconds: 100) wait. "Suspends current process for 100 milliseconds, allowing process2 to run" Transcript show: ' The END'. Executing the example causes "Hello, ...world! The END" to be printed on the system transcript. The Smalltalk debugger can be used on any Context, and hence it can be used to debug any Process. For more information, you can check out one or more of the Smalltalk FAQs: http://st-www.cs.uiuc.edu/users/dnsmith/SmallFaq.html http://scam.XCF.Berkeley.EDU/pub/misc/smalltalk/FAQ/ Most good bookstores will have books on Smalltalk programming. The college library should also be checked. And you can get a free Smalltalk system from the following URLs: LearningWorks: http://sumeru.stanford.edu/learningworks/ SmalltalkExpress: http://www.objectshare.com/osi/main/stexpress/introstexpress.htm URLs for commercial implementations (which usually have drastic discounts for students and educators): Smalltalk MT: http://www.objectconnect.com/intro.htm VisualWorks and VisualSmalltalk: http://www.parcplace.com IBM Smalltalk/VisualAge: http://www.software.ibm.com/software/ad/vastub.html Dolphin Smalltalk: http://www.intuitive.co.uk Gemstone Smalltalk: http://www.gemstone.com/ SmalltalkAgents: http://www.qks.com/ -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|