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?
Please email me. Thank you all for your time.
-Sean Walton
······@oclc.org
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! |
········@concentric.net |==============================================|
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?
Yes. Ada supports threading (simultaneous subprocesses of a single
program).
> 2. What are the language elements?
The language element which enables threads is a TASK. Ada also supports
IPC via a mechanism called RANDEVOUZ.
> 3. How are individual threads accessed within the language?
Each thread is an instance of a TASK TYPE. Instances can be refrenced
like any
other variable (by their name, address etc.), including arrays of
threads, etc.
To pass information between threads, you can use RANDEVOUZs, which are
agreed
"meething places" where two threads can "meet" and "talk" (pass
information).
> 4. How do you debug threads within this language?
Depends on your debbuger and environment. I know my debbuger (Verdix
SELF for
IBM RS6000, AIX) has to ability to set breakpoints at specific tasks,
and I think
that should be the case for any decent ADA debugger.
> 5. Where are sources of information for further study?
The infamous ADA LRM (which can be found online on the web as well), and
ofcourse
various books dealing with ADA.
Good luck with your FAQ,
Calius.
In article <·············@netvision.net.il>, Calius <···@netvision.net.il> writes:
> 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:
>> 4. How do you debug threads within this language?
>
> Depends on your debbuger and environment. I know my debbuger (Verdix
> SELF for
> IBM RS6000, AIX) has to ability to set breakpoints at specific tasks,
> and I think
> that should be the case for any decent ADA debugger.
As another example of the debug situation for a specific environment,
the VMS Debugger offers the following elements specific to Ada, most
of which have to do with tasking (threads):
DBG> show event_facility
event facility is ADA
The general forms of commands to set a breakpoint or tracepoint
on an Ada event are:
SET BREAK/EVENT=event [task[, ... ]] [WHEN(expr)] [DO(comnd[; ... ])]
SET TRACE/EVENT=event [task[, ... ]] [WHEN(expr)] [DO(comnd[; ... ])]
If tasks are specified, the breakpoint will trigger only if the
event occurs for those specific tasks.
Ada event names and their definitions
ABORT_TERMINATED a task is terminating because of abort
ACTIVATING a task is about to begin its activation
DEPENDENTS_EXCEPTION an exception is about to cause a task to await
dependent tasks
EXCEPTION_TERMINATED a task is terminating because of an exception
HANDLED an exception is about to be handled
HANDLED_OTHERS an exception is about to be handled in an OTHERS handler
PREEMPTED a task is about to be preempted
RENDEZVOUS_EXCEPTION an exception is propagating out of a rendezvous
RUN a task is about to run
SUSPENDED a task is about to be suspended
TERMINATED a task is terminating (including by abort or exception)
DBG>
I think readers of comp.lang.ada would appreciate a one-time posting
of your completed FAQ when completed, so we can get a picture of how
the other half lives.
Larry Kilgallen
[Calius]
> The language element which enables threads is a TASK. Ada also supports
> IPC via a mechanism called RANDEVOUZ.
For the record (especially since there was talk of building a FAQ),
it's spelled "rendezvous". (For those who care, it's french, and the
word is just a concatenation of "rendez vous"; "present yourself",
thus giving "rendezvous" the meaning of an appointed meeting, or the
place for such a meeting.)
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"