I want to continue our communication
(https://sourceforge.net/tracker/?group_id=10894&atid=360894&func=detail&aid=577014)
because the "Thread package
2.5" is available. The package has
been improved in severall ways.
1. It seems that some things
that are offered by the pthreads library can still be done in the
future.
- add missing lock types
(http://www.humanfactor.com/pthreads/pthread-code-
snippets.html)
2. more "convenience" functions for thread
shared variables
"string", "regexp" or "keyed list" from the TclX
extension for example
3. Will a thread that was not preserved
("thread::create" without option "-preserved") exit
immediately?
4. A sub function "names" is available for some
commands. I think that it would be needed for "thread::mutex" and
"thread::cond", too.
5. When will it be possible to query the
mutexes and condition variables by which threads they are
used?
6. The description for "thread::vwait" is missing.
(http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/*checkout*/tcl/thread/doc/html/thread.html)
7.
The function "tsv::lock" is available. How do you think about a similar
function "thread::lock"?
Logged In: YES
user_id=572001
1. Another POSIX item
- semaphores (Comparing Primitives -
http://docs.sun.com/db/doc/806-
6867/6jfpgdcn0?l=de&a=view)
Will this be offered, too?
Logged In: YES
user_id=572001
8. Is the technique "sending TCL scripts" the only inter-thread
communication mechanism with the thread package?
Will "message
ports" (http://www.gnu.org/software/pth/pth-manual.html#message port
communication) be applicable?
Logged In: YES
user_id=572001
9. Is there anything to be careful about forking a new
process?
(http://www.gnu.org/software/pth/pth-
manual.html#process forking)
Logged In: YES
user_id=572001
10. Can the explanation for "spurious thread wake-ups" with the function
"thread::cond wait" become more comprehensible?
(Interrupted
Waits on Condition Variables - http://docs.sun.com/db/doc/806-
6867/6jfpgdcn9?a=view)
Logged In: YES
user_id=95086
1.
Semaphores are ok. So are critical sections and recursive
locks. But, what I want to achieve is *simplicity*. Thread
programming has become pretty simple thanks to the Tcl
compartment thread model. If you look at the tpool.tcl source
you won't find a single condition variable or a mutex. Yet,
relatively complex implementation of threadpool is done with
Tcl alone and it is only about 20% slower than the C-level
implementation. Furthermore, the Tcl implementation costed
about 2 days development. The C-one took 10 days. So,
economically speaking, the Tcl version is the clear winner.
Needles to say that a semaphore can be done in pure Tcl
with a mutex and a condition variable, which the threading
extension already supplies.
2. I will include the keyed-list datastructure in 2.6.
3. It will just have the refcount of 0 meaning that caller of
such "non-preserved" thread may never know wether the
thread is still there for the next operation. But, it will not
exit w/o being told so with a "thread::release"
4. I will shortly revamp the cond/mutex Tcl API support. Watch
for the new TIP. This way the API will be more powerful and
you can get many new info/statistics about the mutex etc.
5. Inherently impossible by pthread alone.
6. There is no such command in the thread package. There
is however thread::wait and it is described.
7. There is already thread::eval which evaluates a script under
the mutex, either implicit or explicit one.
8. I think that the message passing, together with channel
transfer and detach/attach allows one to implement almost
any task.
9. As a script programmer, you can safely do the "exec"
from the MT Tcl shell. The underlying implementation will
do the right thing.
Logged In: YES
user_id=572001
1. I know that all things that are not provided by the package yet can be done by
own additional programming.
But I read the available documentation in
this way that "semaphores" do more (They can be shared between threads
and processes.) and are a synchronization technique with other uses than
mutex and condition variables alone. The following items are also part of the
POSIX standard 1003.1c and may be offered in a future version of the thread
package.
It is good that the thread pool functions were implemented
without locking.
1.1 mutexattr... - http://docs.sun.com/db/doc/806-
6867/6jfpgdcmn?a=view
1.2 mutex_consistent_np, mutex_trylock -
http://docs.sun.com/db/doc/806-6867/6jfpgdcmo?a=view
1.3
condattr... - http://docs.sun.com/db/doc/806-
6867/6jfpgdcmp?a=view
1.4 cond_wait (I assume that the function
"pthread_cond_timedwait" is used by the package.),
cond_reltimedwait_np - http://docs.sun.com/db/doc/806-
6867/6jfpgdcmq?a=view
1.5 sem_... -
http://docs.sun.com/db/doc/806-6867/6jfpgdcmr?a=view
1.6
rwlockattr... - http://docs.sun.com/db/doc/806-
6867/6jfpgdcms?a=view
1.7 rwlock... -
http://docs.sun.com/db/doc/806-6867/6jfpgdcmt?a=view
2.
great
3. Will you add this explanation to the
documentation?
5. Do you know a function library that will help to get
that information?
6. In which package is the call "vwait
forever"?
(You called it "this little bastard" once.)
7. Okay -
Evaluation in a locked mode...
8. What you you mean with "message
passing"?
9. Well, then your implemenation does not need any
special treatment in this case like other threading libraries.
10. Your
answer...?
Thanks
Logged In: YES
user_id=572001
1.8 attr_... - http://docs.sun.com/db/doc/806-6867/6jfpgdcmi?a=view
Logged In: YES
user_id=572001
9. It is good that the TCL behaviour for the function "exec" is different from that
what can be read under "http://docs.sun.com/db/doc/806-
6867/6jfpgdcn4?a=view".
Logged In: YES
user_id=95086
1. Basicaly, the threading extension exposes the Tcl API.
It does *not* add to the API.
Speaking of the API, there are some API corners that need
to be improved and I'm working on that. There will be a
new TIP on this soon.
Yes, all the stuff you've described are ok, but do you
really need them on the script level? I think I might
wrap the rwlocks, although I'm not really convinced that
they are a good thing to use.
3. Sure.
5. You'd need to make your own wrappers arround
pthread_mutex and friends and provide a kind of
debugging mutex implementation where you track
who (which thread) is holding the mutex and be
able to kill the process on deadlock attempts.
I might be proposing this in the upcomming TIP.
The pthread does not do this for you, but you
can make one yourself.
6. Nowhere. It is an idiom one uses frequently
when entering the event loop forever, like in
some server applications, for example.
8. Message passing == script passing. It is basically
the same thing.
10. Ok, the doc is little bit terse on that. I might
get put it more clear.
Logged In: YES
user_id=572001
1. Interesting...
You mentioned "pthreads". - So I made suggestions in
this direction.
I did not know that the programming interface should
improve on the C level before further enhancements can be made. I would
prefer that all functionality of the underlying thread function or class library
will be also provided on the TCL level.
The functions that you are not
convinced to exist because they are needed. The frequency for their usage
patterns is different, of course.
5. I'm curious about that. Please put
the ideas into the TIP.
6. I would prefer an other wording than "vwait".
Would a "waiting on a thread variable" be easier to understand?
Logged In: YES
user_id=572001
1. I add some links to helpful information about algorithms and
technologies.
1.1 Can the API be improved so that an implementation of
the CORBA standard "Concurrency Service"
(http://www.omg.org/technology/documents/corbaservices_spec_catalog.htm,
http://fpx.de/Combat/\) would be possible with TCL?
1.2 Can the
package profit from "Communicating Sequential Processes"
(http://www.cs.ukc.ac.uk/research/groups/crg/research_interests.html)
Logged In: YES
user_id=572001
I point to another good description:
Guide to the POSIX Threads Library -
http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_HTML/ARH9RBTE/TITLE.HTM
newsgroup:
comp.programming.threads
Logged In: YES
user_id=572001
Is cooperative multitasking (like "http://www.gnu.org/software/pth/pth-
manual.html#the compromise of pth") or preemptive multithreading
provided by the internal TCL threads library?
Does this library support
simultanous execution on several processors?
Logged In: YES
user_id=572001
Are the comments from the discussion "library proposal"
(http://groups.google.com/groups?selm=IhBS9.18%
24LJ1.422974%40news.cpqcorp.net) also applicable to the
threads package?
Logged In: YES
user_id=572001
Can anything from the class library "Jsync - collection of synchronization
classes for Java" (http://www.garret.ru/~knizhnik/jsync-1.03/package-
jsync.html) be used for the TIP?
Logged In: YES
user_id=572001
Normative
documentation:
http://www.opengroup.org/onlinepubs/007904975/basedefs/pthread.h.html
Logged In: YES
user_id=95086
We'll soon make a TIP in order to get more of pthreads available
on the C-API so everybody can take advantage of that.
Logged In: YES
user_id=572001
It needs some time to get the function interface
"http://www.tcl.tk/man/tcl8.4/TclLib/Thread.htm" up to date ...
Logged In: YES
user_id=572001
When will this Tcl Improvement Proposal (http://www.tcl.tk/cgi-
bin/tct/tip/2.html) be started?
Logged In: YES
user_id=95086
To submit the TIP one needs to have a reference implementation,
otherwise nothing will happen.
I had very little time to catch up with that so it just keeps
sleeping. Hopefully, times will get better.
Logged In: YES
user_id=79902
Not strictly true, and certainly not to submit it (getting a
vote to accept is slightly different; we've had problems in
the past with TIPs where the author hasn't been able to
arrange implementation effort.) TIPs do require a commitment
of time and effort from *someone* though, as our engineering
standards are rather high.
Logged In: YES
user_id=95086
I know. Chances of getting the TIP accepted are much
higher if there is a ref implementation sitting somewhere.
In this case, I have very little concern about adoption
of the TIP. It is the implementation which troubles me.
Not because of the complexity (it is just adding new
pthreads C-wrappers here and there) but because of
the lack of time.
So, lets see if I'll be able to manage that :)