info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Thread package and mutexes
156 views
Skip to first unread message
Googie
Jul 21, 2012, 9:39:05 AM7/21/12
to
Hi,
Some time ago I argued here about the Tcl Thread package model, which makes each thread work with its own Tcl interpreter.
The argument of others was that this way there are no problems with synchronization, debugging, ...
I still think this is wrong to force developer (instead of giving the choice) for this model, but hey - it is like it is.
I just had another look at Thread manual and I noticed [thread::mutex], [thread::rwmutex] and [thread::cond]. I wonder what are they for, given the current Thread model?
Anybody can explain this? Thanks!
Regards,
Googie
Some time ago I argued here about the Tcl Thread package model, which makes each thread work with its own Tcl interpreter.
The argument of others was that this way there are no problems with synchronization, debugging, ...
I still think this is wrong to force developer (instead of giving the choice) for this model, but hey - it is like it is.
I just had another look at Thread manual and I noticed [thread::mutex], [thread::rwmutex] and [thread::cond]. I wonder what are they for, given the current Thread model?
Anybody can explain this? Thanks!
Regards,
Googie
Georgios Petasis
Jul 21, 2012, 1:32:42 PM7/21/12
to
But perhaps they are needed in case you want to lock something not
tcl-related (i.e. a serial port or a file, or what ever...)
George
Twylite
Aug 16, 2012, 6:56:26 AM8/16/12
to
On Saturday, 21 July 2012 15:39:05 UTC+2, Googie wrote:
> Some time ago I argued here about the Tcl Thread package model, which makes each thread work with its own Tcl interpreter.
> Some time ago I argued here about the Tcl Thread package model, which makes each thread work with its own Tcl interpreter.
> I still think this is wrong to force developer (instead of giving the choice) for this model, but hey - it is like it is.
It's not that simple. Tcl's internals assume that each interp can only be executed in a single thread, allowing for a number of performance improvements. For example per-thread memory allocation, and avoiding locks when handling (internal) objects/structs and refcounts. Existing Tcl scripts also rely on this behaviour (you don't have to worry about writing 'thread-safe' code because the interp is isolated). In short Tcl follows the *nix multi-processing model rather than the multi-threading model that is more commonly associated with Windows and Java.
> I just had another look at Thread manual and I noticed [thread::mutex], [thread::rwmutex] and [thread::cond]. I wonder what are they for, given the current Thread model?
Regards,
Twylite
Googie
Aug 20, 2012, 9:18:22 AM8/20/12
to
> > I just had another look at Thread manual and I noticed [thread::mutex], [thread::rwmutex] and [thread::cond]. I wonder what are they for, given the current Thread model?
>
> Synchronization between threads. Sometimes you want threads to operate in concert rather than independently.
Arjen Markus
Aug 20, 2012, 9:40:21 AM8/20/12
to
Op maandag 20 augustus 2012 15:18:22 UTC+2 schreef Googie het volgende:
Concurrent access is mostly, but not entirely, handled transparently by the
Thread package. You can use mutexes and condition variables for synchronisation:
some threads waiting for the master thread for instance or all threads need
to arrive at some point in the processing before they can continue.
One simple example: reporting the results of a computation in a predictable
order requires that one thread takes the lead and prints these results. The
others will have to supply the information and wait until all is done.
Regards,
Arjen
> > > I just had another look at Thread manual and I noticed [thread::mutex], [thread::rwmutex] and [thread::cond]. I wonder what are they for, given the current Thread model?
>
> >
>
> > Synchronization between threads. Sometimes you want threads to operate in concert rather than independently.
>
>
>
> What would you need to synchronize, if there's no concurrent access problem?
There is a concurrent access problem, but due to the each-interpreter-belongs-to-one-thread model, it is not as big as with most other languages.
>
> >
>
> > Synchronization between threads. Sometimes you want threads to operate in concert rather than independently.
>
>
>
> What would you need to synchronize, if there's no concurrent access problem?
Concurrent access is mostly, but not entirely, handled transparently by the
Thread package. You can use mutexes and condition variables for synchronisation:
some threads waiting for the master thread for instance or all threads need
to arrive at some point in the processing before they can continue.
One simple example: reporting the results of a computation in a predictable
order requires that one thread takes the lead and prints these results. The
others will have to supply the information and wait until all is done.
Regards,
Arjen
Googie
Aug 20, 2012, 4:22:34 PM8/20/12
to
> > What would you need to synchronize, if there's no concurrent access problem?
>
> There is a concurrent access problem, but due to the each-interpreter-belongs-to-one-thread model, it is not as big as with most other languages.
>
> Concurrent access is mostly, but not entirely, handled transparently by the
> Thread package. You can use mutexes and condition variables for synchronisation:
> some threads waiting for the master thread for instance or all threads need
> to arrive at some point in the processing before they can continue.
>
> One simple example: reporting the results of a computation in a predictable
> order requires that one thread takes the lead and prints these results. The
> others will have to supply the information and wait until all is done.
The way I see it is that the Thread package handles concurrent access problem entirely by having an interpreter per a thread. There is no concurrent access issue with any resource. Period. If you disagree - name one resource affected by this problem (note, that channels are transferable, but also exclusive to a single interpreter) and I will honestly respect that.
>
> There is a concurrent access problem, but due to the each-interpreter-belongs-to-one-thread model, it is not as big as with most other languages.
>
> Concurrent access is mostly, but not entirely, handled transparently by the
> Thread package. You can use mutexes and condition variables for synchronisation:
> some threads waiting for the master thread for instance or all threads need
> to arrive at some point in the processing before they can continue.
>
> One simple example: reporting the results of a computation in a predictable
> order requires that one thread takes the lead and prints these results. The
> others will have to supply the information and wait until all is done.
In regards of threads synchronization against some common entry/exit point - you always could use inter-thread messaging. Actually, I do this a lot in my multithreaded Tcl apps. No need for mutexes.
What I'm trying to say is that mutex (and conditional variable) is a try to include some of multithreading primitives that do not belong to the multithreading model implemented for Tcl. They are designed to deal with the resource concurrent access problem, but there's none.
Unless Tcl mutex is just a high level routine to help synchronizing threads on entry/exit point - and only for that. If that's the case, then it's fine, I'm just not sure if the name is right - could be misleading on how is Tcl multithreading model implemented.
Regards,
Pawel
Christian Gollwitzer
Aug 20, 2012, 4:49:22 PM8/20/12
to
Am 20.08.12 22:22, schrieb Googie:
used to serialize access to shared memory. This is indeed not necessary
in Tcl because of the separate interpreters per thread. Also, the shared
variables (tsv:: and friends) are implicitly locked.
But note, that this holds only for resources directly managed by Tcl.
There can be external resources other than that. For instance, consider
an external file holding the result of a computation. Every time a
thread finishes computation, a column is appended to the external file.
You could do it like this:
========== 8>< ===============
set myresult [compute]
set fd [open output.dat r]
set lines [split $fd \n]
close $fd
set result {}
foreach res $myresult line $lines {
lappend result [list {*}$line $res]
}
set fd [open output.dat w]
puts -nonewline $fd [join $result \n]
close $fd
========== 8>< ================
As you can trivially see, this will result in a mess, loss of results,
strange mixing, crash... when more than one thread tries to modify the
file. This is a race condition, and it will happen, and it's *very* hard
to debug, and Tcl can nothing do to it by itself. Of course, there are
different methods to deal with it, like sending the result back to one
coordinator thread. Locking using a mutex is just another method, and
there is nothing wrong with providing that option.
Christian
> The way I see it is that the Thread package handles concurrent access
> problem entirely by having an interpreter per a thread. There is no
> concurrent access issue with any resource. Period. If you disagree -
> name one resource affected by this problem (note, that channels are
> transferable, but also exclusive to a single interpreter) and I will
> honestly respect that.
In typical low-level multithreading applications, mutexes are mostly
> problem entirely by having an interpreter per a thread. There is no
> concurrent access issue with any resource. Period. If you disagree -
> name one resource affected by this problem (note, that channels are
> transferable, but also exclusive to a single interpreter) and I will
> honestly respect that.
used to serialize access to shared memory. This is indeed not necessary
in Tcl because of the separate interpreters per thread. Also, the shared
variables (tsv:: and friends) are implicitly locked.
But note, that this holds only for resources directly managed by Tcl.
There can be external resources other than that. For instance, consider
an external file holding the result of a computation. Every time a
thread finishes computation, a column is appended to the external file.
You could do it like this:
========== 8>< ===============
set myresult [compute]
set fd [open output.dat r]
set lines [split $fd \n]
close $fd
set result {}
foreach res $myresult line $lines {
lappend result [list {*}$line $res]
}
set fd [open output.dat w]
puts -nonewline $fd [join $result \n]
close $fd
========== 8>< ================
As you can trivially see, this will result in a mess, loss of results,
strange mixing, crash... when more than one thread tries to modify the
file. This is a race condition, and it will happen, and it's *very* hard
to debug, and Tcl can nothing do to it by itself. Of course, there are
different methods to deal with it, like sending the result back to one
coordinator thread. Locking using a mutex is just another method, and
there is nothing wrong with providing that option.
Christian
Googie
Aug 20, 2012, 5:24:37 PM8/20/12
to
> As you can trivially see, this will result in a mess, loss of results,
> strange mixing, crash... when more than one thread tries to modify the
> file. This is a race condition, and it will happen, and it's *very* hard
> to debug, and Tcl can nothing do to it by itself. Of course, there are
> different methods to deal with it, like sending the result back to one
> coordinator thread. Locking using a mutex is just another method, and
> there is nothing wrong with providing that option.
Okay, that makes sense. I agree.
> strange mixing, crash... when more than one thread tries to modify the
> file. This is a race condition, and it will happen, and it's *very* hard
> to debug, and Tcl can nothing do to it by itself. Of course, there are
> different methods to deal with it, like sending the result back to one
> coordinator thread. Locking using a mutex is just another method, and
> there is nothing wrong with providing that option.
Regards,
Pawel
0 new messages