tcl-threads — Discussion of threading in Tcl and the Thread extension.

AW: [Tcl-Threads] more synchronization primitives for the threads package

[Elfring, M. <EL...@Me...>]

1. I add that the specified mutex must be used by the target thread to
ensure that only this one will execute the unsafe function(s).
   The command "thread::eval -lock $myMutex ..." can only lock the calling
thread and not the called target.

[Tcl-Threads] Why is threads not part of the TCL core?

[Ed S. <ed...@ee...>]

I am doing a substantial re-write of my TCL-based Privaria Secure 
Networking Suite, and am disappointed with lack of universal support for 
threads. I had planned to make my user interface more responsive by 
running a couple of threads for behind-the-scenes networking stuff, but 
quickly found that the SuSE 8.1 Linux distribution does not provide TCL 
compiled for threads support.

Most people who use my software have never heard of TCL. They certainly 
aren't going to want to be bothered with recompiling a script language 
interpreter to use a program that promotes its point-and-click simplicity.

So the question is, what possible reason is there for not making *all* 
tclsh/wish distributions support threads?

/--- Ed Suominen ------------------------------\
|> Registered Patent Agent
|> Independent Inventor of EE Technology
|> Author, PRIVARIA Secure Networking Suite
||  Freely available at http://www.privaria.org
\--- http://www.eepatents.com -----------------/

[Tcl-Threads] more synchronization primitives for the threads package

[Elfring, M. <EL...@Me...>]

Hallo,

I want to continue the discussion "call for a function that is not thread
safe"
(https://sourceforge.net/tracker/index.php?func=detail&aid=674367&group_id=1
0894&atid=360894) about this medium.

1. I would like that a command like the following will be added to the
threads package.
thread::send -lock $myMutex $TID {Connection::create} result

Users will need that to call functions easily that can not be trusted to be
thread-safe. The unsafe function will be executed in a synchronous and
atomic fashion. It will be guaranteed that the mutex will be unlocked
automatically.


2. Mutual exclusions and condition variables are synchronization primitives
that are available today.
I would like to use the other primitives, too.
http://www.opengroup.org/onlinepubs/007904975/basedefs/pthread.h.html

2.1 critical regions
2.2 semaphores
2.3 recursive mutexes
2.4 read/write locks
2.5 monitors 
2.6 barriers
2.7 mutual exclusion with busy waiting (spin locks)

Sincerely,
Markus Elfring