#254 development targets: Complete pthreads?

open
6
2004-03-19
2002-12-27
No

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"?

Discussion

1 2 > >> (Page 1 of 2)
  • Markus Elfring

    Markus Elfring - 2002-12-27

    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?

     
  • Markus Elfring

    Markus Elfring - 2002-12-28

    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?

     
  • Markus Elfring

    Markus Elfring - 2002-12-28

    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)

     
  • Markus Elfring

    Markus Elfring - 2002-12-28

    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)

     
  • Zoran Vasiljevic

    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.

     
  • Markus Elfring

    Markus Elfring - 2002-12-28

    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

     
  • Markus Elfring

    Markus Elfring - 2002-12-28

    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".

     
  • Zoran Vasiljevic

    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.

     
  • Markus Elfring

    Markus Elfring - 2002-12-28

    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?

     
  • Markus Elfring

    Markus Elfring - 2002-12-30

    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)

     
  • Markus Elfring

    Markus Elfring - 2003-01-05

    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?

     
  • Markus Elfring

    Markus Elfring - 2003-01-08

    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?

     
  • Markus Elfring

    Markus Elfring - 2003-01-12

    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?

     
  • Zoran Vasiljevic

    • status: open --> closed
     
  • Zoran Vasiljevic

    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.

     
  • Markus Elfring

    Markus Elfring - 2003-08-16

    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 ...

     
  • Markus Elfring

    Markus Elfring - 2003-08-23
    • status: closed --> pending
     
  • Markus Elfring

    Markus Elfring - 2003-08-23

    Logged In: YES
    user_id=572001

    When will this Tcl Improvement Proposal (http://www.tcl.tk/cgi-
    bin/tct/tip/2.html) be started?

     
  • Zoran Vasiljevic

    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.

     
  • Donal K. Fellows

    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.

     
  • Zoran Vasiljevic

    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 :)

     
  • Markus Elfring

    Markus Elfring - 2003-08-25
    • status: pending --> open
     
1 2 > >> (Page 1 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks