Tcl-URL! - weekly Tcl news and links (Feb 4)
Cameron Laird
multi-threaded application is deadlock free." - Matthew Sackman
http://www.wellquite.org/shared_mutable_memory_must_die.html
"I haven't yet seen a regexp that saved my time before writing it, during
writing it or after writing it." - dour Kaitzschu
Alexandre Ferrieux and Georgios Petasis, among others, exhibit
dexterity in manipulating strings, with a range of dependence
on the [regexp] engine:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/a9e1feaa6c962be1/
Notice how nicely this thread illustrates there will always be
a market for programmers, where "programmer" is understood to
mean not, "code-monkey", but, "someone with the ability to de-
tect and resolve ambiguitities in conventional human discourse".
Alex also compares Tcl's dictionaries and associative arrays:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/2bf9f3fce920415e/
George and others give lessons in Teacup use--that is, in use
of standard extensions with the latest Tcl release:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/d267bac27fad2a76/
Please be aware that [regsub] is NOT a universal solution; at
the same time, its effectiveness sometimes is multiplied when
it's teamed with other techniques:
http://groups.google.com/group/comp.lang.tcl/msg/58ae9e80a7b8f934
http://www.unixreview.com/documents/s=9884/ur0509m/
Thanks to Arjen Markus for his weekly summary of Wiki action:
Again a week has passed, time for a summary of what happened on the Wiki:
Only too human
- Ever wondered about the number systems of other peoples and cultures?
Here is a library that might interest you: <http://wiki.tcl.tk/17692>
- Just go and build in a spellchecker in your application. This
page should help out: <http://wiki.tcl.tk/17380>
- And just to stress that Tcl can be used for other things than
serious applications: <http:/wiki.tcl.tk/10356> for translations
to Pig Latin.
- Sometimes you just need the information on the Wiki as such,
without a need to be online. Download a static database then:
<http://wiki.tcl.tk/20412>
Typical stuff
- Getting notified of changes to files in a directory - that
can be quite useful. Try: <http://wiki.tcl.tk/3643> and the
pages it links to.
- The Wiki has a long tradition of Tcl mimicking another
language or system - the Bourne shell is one such other system:
<http://wiki.tcl.tk/2932>
- And last but not least: yet another 3D demo. Check out
<http://wiki.tcl.tk/17771>
Everything Tcl-related you want is probably one or two clicks away in these
pages:
The "Welcome to comp.lang.tcl" message by Andreas Kupries
http://www.purl.org/net/tcl-welcome
comp.lang.tcl is a crucial resource for Tcl practitioners.
An interesting perspective on its traffic appears at
http://groups.google.com/group/comp.lang.tcl/about
The Tcl Developer Site is Tcl's "home base".
http://www.tcl.tk
Larry Virden maintains a comp.lang.tcl FAQ launcher.
http://www.purl.org/NET/Tcl-FAQ/
The Tcl Developer Xchange is a highly organized resource center
of documents and software with provisions for individuals to
maintain references to their own software:
http://www.tcl.tk/resource/
The TDX sponsor, ActiveState, also keeps info to convince your
boss Tcl is a good thing
http://www.tcl.tk/scripting/
The Tcl'ers Wiki is a huge, dynamic, collaboratively edited repository
of documentation, examples, tutorials and pontifications on all things
Tcl.
http://wiki.tcl.tk/0
For the ideal overview of the topics about Tcl most likely to
interest a newcomer, see "Arts and Crafts ..."
http://wiki.tcl.tk/969
There's also a high-quality Wikibook on Tcl:
http://en.wikibooks.org/wiki/Programming:Tcl
ActiveState maintains binaries distribution and development tools
http://www.activestate.com/Tcl
along with a Cookbook of Tcl recipes
http://aspn.activestate.com/ASPN/Cookbook/Tcl
"La Gazette du Técleux" is an important monthly publication.
http://wfr.tcl.tk/1159
deli.cio.us presents an intriguing approach to reference commentary.
It already aggregates quite a bit of Tcl intelligence.
http://del.icio.us/tag/tcl
Cameron Laird tracks several Tcl/Tk references of interest (but
needs to validate many of the links).
http://phaseit.net/claird/comp.lang.tcl/
Years ago, Cetus Links maintained a Tcl/Tk page with verified links
http://www.cetus-links.org/oo_tcl_tk.html
"Yahoo! Groups" archives comp.lang.tcl.announce posts--even
though clta itself is dormant.
http://groups.yahoo.com/group/tcl_announce/
We're working on more useful archives of past installments. In the
meantime, an alternative is
http://groups.google.com/groups?oi=djq&as_q=+Tcl-URL&as_ugroup=comp.lang.tcl
Suggestions/corrections for next week's posting are always welcome.
To receive a new issue of this posting in e-mail each Monday, ask
<cla...@phaseit.net> to subscribe. Be sure to mention "Tcl-URL!".
--
Phaseit, Inc. (http://phaseit.net) is pleased to participate in and
sponsor the "Tcl-URL!" project.
Darren New
> QOTW: "[I]t's simply unwise to ever believe that any non-trivial
> multi-threaded application is deadlock free." - Matthew Sackman
I must have missed this post, but it's clearly an inaccurate statement
on the face of it. :-) There are known ways to guarantee
deadlock-freeness, for one thing.
--
Darren New / San Diego, CA, USA (PST)
On what day did God create the body thetans?
Óscar Fuentes
> Cameron Laird wrote:
>> QOTW: "[I]t's simply unwise to ever believe that any non-trivial
>> multi-threaded application is deadlock free." - Matthew Sackman
>
> I must have missed this post, but it's clearly an inaccurate statement
> on the face of it. :-) There are known ways to guarantee
> deadlock-freeness, for one thing.
I guess that the author of the phrase would rebut saying that those
ways are not trivial, by his own definition of "trivial" :-)
Good for the QOTW, nonetheless, as we expect there statements more
appropiate for a politico than for a technician. :-)
--
Oscar
Darren New
> Darren New <dn...@san.rr.com> writes:
>
>> Cameron Laird wrote:
>>> QOTW: "[I]t's simply unwise to ever believe that any non-trivial
>>> multi-threaded application is deadlock free." - Matthew Sackman
>> I must have missed this post, but it's clearly an inaccurate statement
>> on the face of it. :-) There are known ways to guarantee
>> deadlock-freeness, for one thing.
>
> I guess that the author of the phrase would rebut saying that those
> ways are not trivial, by his own definition of "trivial" :-)
No, they're pretty trivial:
1) Have all people locking things lock them in the same order.
I.e., avoid circularities in the lock graph.
E.g., ISDN's over-the-wire packet allocation mechanism.
2) Don't wait for a resource while holding a lock on a resource.
If your lock request fails, roll back and start again.
3) Don't lock multiple resources at the same time.
Lock everything at the start that you need.
Not uncommon in batch-processing OSes.
4) Allow preemption of locks.
E.g., virtual memory getting paged out.
Useful when you can break a lock and then restore
back to the state before you had the lock.
5) Don't lock anything. Organize your code such that
each memory address is only written to by one
program.
I wouldn't call the various operating systems and database managers I've
worked with "trivial", nor would I call the interaction between ISDN
devices or USB devices "trivial". Yet these things all run years and
years without experiencing deadlock.
Yes, you have to actively code for deadlock prevention. Yes, it can put
a crimp in what you're doing, and make it less efficient as well.
Tom Conner
> "I haven't yet seen a regexp that saved my time before writing it, during
> writing it or after writing it." - dour Kaitzschu
>
Don't forget the time spent later trying to figure out what it is doing, and
all the grief it causes others who need to maintain the code.
Donal K. Fellows
> Yes, you have to actively code for deadlock prevention. Yes, it can put
> a crimp in what you're doing, and make it less efficient as well.
But remember this: you don't get much *less* efficient than a
deadlocked program. (There are other ways to analyse programs to
determine if they can deadlock, e.g. model checking, but they tend to
not scale all that well with the size of the program to be analysed.)
Donal.
Jay Rohr
> But remember this: you don't get much *less* efficient than a
> deadlocked program.
Quote for next week!
Neil Madden
Only 5 seems in any way trivial to me.
> I wouldn't call the various operating systems and database managers I've
> worked with "trivial", nor would I call the interaction between ISDN
> devices or USB devices "trivial". Yet these things all run years and
> years without experiencing deadlock.
Errr... this doesn't seem to back up your point. Surely they aren't
trivial precisely because they have to take so much care to avoid deadlock?
-- Neil
Darren New
> Only 5 seems in any way trivial to me.
Having only one lock is pretty trivial. Locking everything you're going
to use for the program, in alphabetical order, at the start of the
program, is pretty trivial.
The Banker's Algorithm isn't *that* hard.
> Errr... this doesn't seem to back up your point. Surely they aren't
> trivial precisely because they have to take so much care to avoid deadlock?
They don't take that much care. Besides, the quote basically said
"non-trivial programs deadlock." I'm pointing out how you can avoid it.
Not necessarily trivially, but with guaranteed assurances.
Neil Madden
> Neil Madden wrote:
>> Only 5 seems in any way trivial to me.
>
> Having only one lock is pretty trivial. Locking everything you're going
> to use for the program, in alphabetical order, at the start of the
> program, is pretty trivial.
But knowing what resources you need, and what resources every library
routine you call needs, is not trivial in most cases. It requires
knowing the implementation details of every library procedure you call.
-- Neil
Darren New
Depends on the level of locking. This works best when the sort of thing
you're locking is "I'll need two tape drives, four dedicated processors,
and 20 minutes on the film burner to render this movie clip. Let me know..."
Or "this query will need to lock the employee's table, the taxes table,
and will need a write lock on the checks-to-print table."
If you're talking about individual objects, like at the
programming-language level, yeah, it's harder.
Donal K. Fellows
> Depends on the level of locking. This works best when the sort of thing
> you're locking is "I'll need two tape drives, four dedicated processors,
> and 20 minutes on the film burner to render this movie clip. Let me
> know..."
>
> Or "this query will need to lock the employee's table, the taxes table,
> and will need a write lock on the checks-to-print table."
>
> If you're talking about individual objects, like at the
> programming-language level, yeah, it's harder.
This is because deadlock-freedom is a global property, rather like
security or buglessness. With such things, the smallest unit that you
can analyse and get a strong answer on is a whole application, and often
you need to go up to analysing entire systems. Which takes you straight
into the territory of intractability. :-\ The easiest way to deal with
such things is to write highly robust modules that (to as great an
extent as possible) don't lock anything, allowing you to subdivide the
problem and factor out stuff that (you hope) doesn't matter.
But this is a general computing problem, and not Tcl-specific. Tcl's
actually pretty good in this regard. :-)
Donal.
Darren New
> This is because deadlock-freedom is a global property,
Good point.
> But this is a general computing problem, and not Tcl-specific. Tcl's
> actually pretty good in this regard. :-)
Three cheers for the event loop. :-)
Andreas Leitgeb
> Donal K. Fellows wrote:
>> But this is a general computing problem, and not Tcl-specific. Tcl's
>> actually pretty good in this regard. :-)
> Three cheers for the event loop. :-)
Until you get struck by a nested vwait that
prevents your outer vwait from finishing...
Darren New
> Until you get struck by a nested vwait that
> prevents your outer vwait from finishing...
Yeah, well, three cheers for continuations! ;-)
Or another one: you have a vwait going, and you kill off all [after]
jobs in an [after] job (as in when you get a signal). Now you bomb out
with a "would wait forever" error.