From: SourceForge.net <no...@so...> - 2003-08-16 09:57:59
|
Feature Requests item #659131, was opened at 2002-12-27 21:19 Message generated for change (Comment added) made by elfring You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=659131&group_id=10894 Category: 80. Thread Package Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Markus Elfring (elfring) Assigned to: Zoran Vasiljevic (vasiljevic) Summary: development targets: Complete pthreads? Initial Comment: 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"? ---------------------------------------------------------------------- >Comment By: Markus Elfring (elfring) Date: 2003-08-16 11:43 Message: 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 ... ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2003-05-30 18:44 Message: 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. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-01-12 19:00 Message: Logged In: YES user_id=572001 Normative documentation: http://www.opengroup.org/onlinepubs/007904975/basedefs/pthread.h.html ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-01-12 18:12 Message: 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? ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-01-08 12:08 Message: 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? ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-01-05 11:47 Message: 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? ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-01-04 13:33 Message: 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 ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2002-12-30 22:14 Message: 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) ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2002-12-28 23:40 Message: 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? ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2002-12-28 19:29 Message: 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. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2002-12-28 19:06 Message: 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". ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2002-12-28 18:39 Message: Logged In: YES user_id=572001 1.8 attr_... - http://docs.sun.com/db/doc/806-6867/6jfpgdcmi?a=view ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2002-12-28 18:25 Message: 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 ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2002-12-28 15:06 Message: 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. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2002-12-28 14:57 Message: 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) ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2002-12-28 14:33 Message: 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) ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2002-12-28 14:13 Message: 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? ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2002-12-27 22:10 Message: 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=659131&group_id=10894 |