Thread Newbie
Francois Fernandes
Where can I find some informations, tutorials and examples about threads under
LinuX and windows. I'm a threads newbie, because I've never used them.
thx for every suggestion
Josh Jones
www.google.com , search for "pthreads", or maybe "multithreaded" ...?
--
J o s h u a J o n e s / www.intmain.net / jajones(at)cc.gatech.edu
__ .~.
College of Computing at the | / / _ _ _ _ _ __ __ /V\
Georgia Institue of Technology | / /__ / / / \// //_// \ \/ / // \\
Atlanta, Georgia, U.S. | /____/ /_/ /_/\/ /___/ /_/\_\ /( )\
*Debian GNU/Linux* ^^-^^
David Butenhof
>
> Where can I find some informations, tutorials and examples about threads
> under LinuX and windows. I'm a threads newbie, because I've never used
> them.
There's lots of material on the web; do a search. If you want reliable
details, though, you should buy yourself a book. (Or more than one.) Good
places to start are mine (Programming with POSIX Threads, Addison-Wesley)
and Bil Lewis' (Programming with Pthreads, SunSoft/Prentice-Hall).
Also, "out of the box", you'll find POSIX threads on nearly any UNIX-ish
system out there, including Linux and the BSD variants (FreeBSD, NetBSD,
Darwin, Mac OS X). You'll also find POSIX threads (or a substantial subset)
on many non-UNIX systems, including OS/400 and OpenVMS.
You will not, however, find POSIX threads on Windows systems. Microsoft
doesn't like standards, and uses its own proprietary Win32 threading model.
There are books written about that, too, including Multithreading
Applications in Win32 (Beveridge/Wiener, Addison-Wesley). Or, you can pick
up an opensource "mostly POSIX threads" library that runs on top of Win32,
and use that.
/------------------[ David.B...@compaq.com ]------------------\
| Compaq Computer Corporation POSIX Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/
Alexander Terekhov
David Butenhof wrote:
[...]
> You will not, however, find POSIX threads on Windows systems. Microsoft
> doesn't like standards, and uses its own proprietary Win32 threading model.
That's, so to speak, a rather old/out-dated MS-stuff! ;-)
The newly-born "ecma.ch-standard" MS-kid on the block
is MS-CLI/C# Java-like threading API/"model".
> There are books written about that, too, including Multithreading
> Applications in Win32 (Beveridge/Wiener, Addison-Wesley).
CLI/C# write-ups:
http://www.ecma.ch/ecma1/STAND/ecma-334.htm
http://www.ecma.ch/ecma1/STAND/ecma-335.htm
http://www.ecma.ch/ecma1/techrep/e-tr-084.htm
Directory of G:\C#\tr-084\2001tc39-020b\System\Threading
10/02/2001 12:44p 546,816 Interlocked.doc
11/14/2001 05:38p 40,519 Interlocked.pdf
10/02/2001 12:44p 568,832 Monitor.doc
11/14/2001 05:36p 56,873 Monitor.pdf
10/02/2001 12:44p 30,208 SynchronizationLockException.doc
11/14/2001 05:36p 20,093 SynchronizationLockException.pdf
10/02/2001 12:44p 686,080 Thread.doc
11/14/2001 05:36p 138,010 Thread.pdf
10/02/2001 12:45p 26,624 ThreadAbortException.doc
11/14/2001 05:36p 17,664 ThreadAbortException.pdf
10/02/2001 12:44p 26,624 ThreadPriority.doc
11/14/2001 05:36p 18,577 ThreadPriority.pdf
10/02/2001 12:45p 21,504 ThreadStart.doc
11/14/2001 05:37p 13,391 ThreadStart.pdf
10/02/2001 12:44p 34,816 ThreadState.doc
11/14/2001 05:37p 23,926 ThreadState.pdf
10/02/2001 12:45p 32,256 ThreadStateException.doc
11/14/2001 05:37p 21,215 ThreadStateException.pdf
10/02/2001 12:45p 22,016 Timeout.doc
11/14/2001 05:37p 14,015 Timeout.pdf
10/02/2001 12:45p 546,816 Timer.doc
11/14/2001 05:37p 41,480 Timer.pdf
10/02/2001 12:45p 23,552 TimerCallback.doc
11/14/2001 05:37p 14,747 TimerCallback.pdf
10/02/2001 12:43p 530,944 WaitHandle.doc
11/14/2001 05:35p 30,514 WaitHandle.pdf
26 File(s) 3,548,112 bytes
and, BTW, some interesting comments:
http://www.cs.umd.edu/~pugh/java/memoryModel/archive/0938.html
> Or, you can pick
> up an opensource "mostly POSIX threads" library that runs on top of Win32,
> and use that.
http://sources.redhat.com/pthreads-win32
regards,
alexander.
Michael E Thomadakis
On Mon, 11 Mar 2002, Alexander Terekhov wrote:
> Date: Mon, 11 Mar 2002 14:31:36 +0100
> From: Alexander Terekhov <tere...@web.de>
> Newsgroups: comp.programming.threads
> Subject: Re: Thread Newbie
>
>
> David Butenhof wrote:
> [...]
> > You will not, however, find POSIX threads on Windows systems. Microsoft
> > doesn't like standards, and uses its own proprietary Win32 threading model.
>
> That's, so to speak, a rather old/out-dated MS-stuff! ;-)
>
> The newly-born "ecma.ch-standard" MS-kid on the block
> is MS-CLI/C# Java-like threading API/"model".
How does MS-CLI/C# relate/compare to POSIX threads? Pthreads' definitions
and semantics have been debated for several years by academicians and
developers, leveraging on experience in operating systems theory and
practices.
The only comparable model to Pthreads on MS plattforms would be the
the threading in win32.
Alexander Terekhov
Michael E Thomadakis wrote:
[...]
> > The newly-born "ecma.ch-standard" MS-kid on the block
> > is MS-CLI/C# Java-like threading API/"model".
>
> How does MS-CLI/C# relate/compare to POSIX threads?
AFAICT, MS-CLI/C# threading is even worse than Java... ;-)
> Pthreads' definitions
> and semantics have been debated for several years by academicians
Well, recently, academia became the Java-only stronghold,
unfortunately, IMHO.
> and
> developers, leveraging on experience in operating systems theory and
> practices.
>
> The only comparable model to Pthreads on MS plattforms would be the
> the threading in win32.
Pthreads is a C/... source code level ANSI/IEEE standard
(and "official" ANSI-C extension).
Java is a VM.
MS-CLI/C# is a VM too.
Win32 is practically Wintel-BOX... and/or VMware VM[1]
hosted on IA32 linux box ;-)
So pick your choice... hint: http://sources.redhat.com/pthreads-win32
Also, consider (see "COPYING" in CVS):
"Although pthreads-win32 makes it possible for applications
that use POSIX threads to be ported to Win32 platforms, the
broader goal of the project is to encourage the use of open
standards, and in particular, to make it just a little easier
for developers writing Win32 applications to consider
widening the potential market for their products"
regards,
alexander.
Joe Seigh
Michael E Thomadakis wrote:
...
> How does MS-CLI/C# relate/compare to POSIX threads? Pthreads' definitions
> and semantics have been debated for several years by academicians and
> developers, leveraging on experience in operating systems theory and
> practices.
C# doesn't use the java thread model. It's based on win32 threads AFAIK.
Porting from java to C# will be major fun.
Joe Seigh
Alexander Terekhov
Joe Seigh wrote:
>
> Michael E Thomadakis wrote:
> ...
> > How does MS-CLI/C# relate/compare to POSIX threads? Pthreads' definitions
> > and semantics have been debated for several years by academicians and
> > developers, leveraging on experience in operating systems theory and
> > practices.
>
> C# doesn't use the java thread model.
Java "thread model" is currently under intense
scrutiny, ongoing revision (via JCP process):
http://www.jcp.org/jsr/detail/001.jsp
http://www.jcp.org/jsr/detail/133.jsp
http://www.jcp.org/jsr/detail/166.jsp
> It's based on win32 threads AFAIK.
Yeah, especially MS-CLI/C# ("Assembly: Mscorlib
(in Mscorlib.dll)") *PULSARS*: ;-)
> Porting from java to C# will be major fun.
Not only "porting from java", AFAICT! ;-)
regards,
alexander.
Joe Seigh
Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> >
> > Michael E Thomadakis wrote:
> > ...
> > > How does MS-CLI/C# relate/compare to POSIX threads? Pthreads' definitions
> > > and semantics have been debated for several years by academicians and
> > > developers, leveraging on experience in operating systems theory and
> > > practices.
> >
> > C# doesn't use the java thread model.
>
> Java "thread model" is currently under intense
> scrutiny, ongoing revision (via JCP process):
>
> http://www.jcp.org/jsr/detail/001.jsp
> http://www.jcp.org/jsr/detail/133.jsp
> http://www.jcp.org/jsr/detail/166.jsp
Interesting. I think I was the one that raised the memory visibility issue
for new objects. In comp.lang.java.programmer, subject: visibility of new
object memory state.
http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&selm=1998Apr7.093117%40bose.com
http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&selm=1998Apr8.081242%40bose.com
As far as simplifying java thread semantics, I think that is a good idea but it can be simplified
considerably further. They don't seem to be able to state semantics in terms of observable behavior,
so they resort to describing them in terms of a meta-implementation, a memory model. This complicates
doing program proofs since this meta-implementation shows up as part of your proof. You can see this
where they specify semantics for lock and unlock actions. Well, there's nothing observable from a
program point of view for lock and unlock actions. It's only in other interactions that you can make
inferences from. Anyway, behavioral semantics would look something like this
There almost no memory model to speak of, just that where observable, stores appear to be totally
ordered and deterministic. There's some sort of arbitration mechanism there but I haven't delved
into it.
Interestingly enough, even if they do switch to the proposed semantics, you could still come up with
behavioral semantics and show equivalence of the two.
Joe Seigh
Alexander Terekhov
Joe Seigh wrote:
[...]
> > http://www.jcp.org/jsr/detail/001.jsp
> > http://www.jcp.org/jsr/detail/133.jsp
> > http://www.jcp.org/jsr/detail/166.jsp
>
> Interesting. I think I was the one that raised the memory visibility issue
> for new objects. In comp.lang.java.programmer, subject: visibility of new
> object memory state.
>
> http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&selm=1998Apr7.093117%40bose.com
Uhmm. Do you mean something along the lines of "P.S." stuff
below? Frankly, I do NOT see any problems... since you need
to have an appropriate SYNCHRONIZATION protocol to pass
dynamically created object refs/ptrs/whatever to other
threads...
> http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&selm=1998Apr8.081242%40bose.com
: It turns out that a new object with all of its fields initialized to
: their default values is not so very interesting from a programming
: point of view. Since you'd have to use explicit synchronization
: anyway to sync the memory state after the init methods have run, the
: issue of an object's initial memory state doesn't exist for
: programming. The issue is still a java security or integrity issue
: however.
http://groups.google.com/groups?as_umsgid=3C8DED28.3154017%40web.de
http://groups.google.com/groups?as_umsgid=3C8CBE40.4530411B%40web.de
regards,
alexander.
P.S. web-archive at http://www.cs.umd.edu/~pugh/java/memoryModel/archive
is lagging a bit -- copy & paste from my Lotus Notes e-mail database:
Please respond to Alexander Terekhov/Germany/IBM@IBMDE
Sent by: owner-java...@cs.umd.edu
To: javamem...@cs.umd.edu
cc:
Subject: Re: JavaMemoryModel: Thread starting in constructors
> OK, this is just a simple example of something I'm trying to fine tune:
>
> class A {
> int x;
> final int y;
> public A(int a, int b) {
> x = a;
> y = b;
> new Thread() {
> public void run() {
> System.out.println("x = " + x + ", y = " + y);
> }}.start();
> }
> }
>
> Assume someone invokes new A(1,2). Which of the might occur?
>
> a) prints x = 1, y = 2
> b) prints x = 0, y = 0
> c) prints x = 0, y = 2
> d) prints x = 1, y = 0
> e) the thread started in the constructor throws a NullPointerException
How about:
f) the thread will be SUSPENDED and RESUMED automatically
on exit from the most-derived class constructor (exceptions
aside);
or, even better:
g) a rather simple mechanism of POST-constructors could be
introduced to SAFELY/MEANINGFULLY exploit the polymorphic
behavior (publish this, start threads, etc) at "construction"
time without all those silly "manual" init()s/factories/final
wrappers, etc.
;-)
regards,
alexander.
-------------------------------
JavaMemoryModel mailing list -
http://www.cs.umd.edu/~pugh/java/memoryModel
Please respond to Alexander Terekhov/Germany/IBM@IBMDE
Sent by: owner-java...@cs.umd.edu
To: javamem...@cs.umd.edu
cc:
Subject: Re: JavaMemoryModel: Thread starting in constructors
> ... But so do other anomalies.
and how does this relates to:
http://www.cs.umd.edu/~pugh/java/memoryModel/semantics.pdf
"If thread T1 starts thread T2, then all actions visible
to T1 at the time it starts T2 become visible to T2
before T2 starts. Similarly, if T1 joins with T2 (waits
for T2 to terminate), then all accesses visible to T2
when T2 terminates are visible to T1 after the join
completes."
<?!>
regards,
alexander.
Jerry Schwarz <jsch...@us.oracle.com>@cs.umd.edu on 03/12/2002 04:46:24
PM
Please respond to Jerry Schwarz <jsch...@us.oracle.com>
Sent by: owner-java...@cs.umd.edu
To: "Joshua Bloch" <joshua...@sun.com>,
<javamem...@cs.umd.edu>,
"Bill Pugh" <pu...@cs.umd.edu>
cc:
Subject: Re: JavaMemoryModel: Thread starting in constructors
At 07:57 PM 3/11/2002, Joshua Bloch wrote:
>Bill,
>
> > OK, this is just a simple example of something I'm trying to fine tune:
> >
> > class A {
> > int x;
> > final int y;
> > public A(int a, int b) {
> > x = a;
> > y = b;
> > new Thread() {
> > public void run() {
> > System.out.println("x = " + x + ", y = " + y);
> > }}.start();
> > }
> > }
> >
> > Assume someone invokes new A(1,2). Which of the might occur?
> >
> > a) prints x = 1, y = 2
> > b) prints x = 0, y = 0
> > c) prints x = 0, y = 2
> > d) prints x = 1, y = 0
> > e) the thread started in the constructor throws a NullPointerException
>
> Clearly I'm being dense here, but why is anything other than (a)
legal?
>I always thought that there was implicit synchronization between a thread
>that started a thread and the thread that it started. If anything besides
>(a) is legal, people will be mightily confused.
> Josh
That was my reaction too, but I slept on it overnight and I think I see
a
subtlety that I overlooked yesterday. When is A.y read? Could it be
read
by the constructor of the Thread instead of by the run method.
This question can be illustrated without threads. Consider the
following
example
public class S {
public final int x;
S() { x = ... ; }
...
}
public class U {
private S s;
public U(S s) { this.s = s; }
public int f() { return s.x; }
}
Is a compiler allowed to transform the definition of U into
public class U' {
private int s_x;
public U(S s) { this.s_x = s.x ; }
public int f() { return s_x; }
}
Obviously, this couldn't be allowed if s.x were not final, but does the
special semantics of final allow it? I would like to say yes because
this
is potentially a significant optimization. The relevance to Bill's
example
is that if this transformation were allowed on the anonymous Thread
class
then
> d) prints x = 1, y = 0
becomes possible.
But so do other anomalies. In particular what if U's are used in
constructors of S. Let's modify S a little
public class S {
public final int x;
private U u;
public S() {
u = new(this);
x = ...; // non-zero value
}
public int f() { return u.f(); }
}
With the optimization in place S.f will return 0. But I don't see any
way
I can justify S.f returning 0, so I guess the optimization can't be
allowed. And so, (d) isn't allowed either.
-- Jerry Schwarz
-------------------------------
JavaMemoryModel mailing list -
http://www.cs.umd.edu/~pugh/java/memoryModel
Please respond to Alexander Terekhov/Germany/IBM@IBMDE
Sent by: owner-java...@cs.umd.edu
To: javamem...@cs.umd.edu
cc:
Subject: Re: JavaMemoryModel: Thread starting in constructors
> More realistically, there could be a wait in the constructor dependent on
> a notify in the thread. This is left as an exercise for the reader.
Well, personally, I would feel really "uncomfortable" knowing
that someone could even touch NOT FULLY constructed object(s)
(even with Java's ZERO "pre-init", partially addressing this
"problem").
With "SUSPEND/RESUME" w.r.t thread.start I just meant that
a "request" to start a thread could remain pending until
completion of poly-object construction to prevent exposing
not-fully constructed objects to a newly created/started
thread(s) (with actual start being the memory sync.point).
I am NOT a friend of async.suspend... however, I would like
to note that async.suspend COULD be made deadlock-free using
something along the lines of pthread_atfork() PREPARE and
PARENT handlers -- sort of "async.suspend-handlers"... which
might be useful in a rather limited set/domain of applications.
regards,
alexander.
Jeremy Manson <jma...@cs.umd.edu>@cs.umd.edu on 03/12/2002 04:54:17 PM
Please respond to Jeremy Manson <jma...@cs.umd.edu>
Sent by: owner-java...@cs.umd.edu
To: javamem...@cs.umd.edu
cc:
Subject: Re: JavaMemoryModel: Thread starting in constructors
>
> How about:
>
> f) the thread will be SUSPENDED and RESUMED automatically
> on exit from the most-derived class constructor (exceptions
> aside);
That doesn't solve the problem in terms of the semantics. There is no
implicit synchronzation associated with Thread.suspend() and
Thread.resume() (nor should there be, I suspect; it's good to stay away
from those methods). Even if you were to use wait/notify, it isn't a
good
idea because the constructor may never end (unless you mean that this
only
applies to threads started on the last line of the constructor), viz.:
class A {
int x;
final int y;
Object lock = new Object();
public A(int a, int b) {
x = a;
y = b;
new Thread() {
public void run() {
System.out.println("x = " + x + ", y = " + y);
}}.start();
}
while (true) {
}
}
More realistically, there could be a wait in the constructor dependent
on
a notify in the thread. This is left as an exercise for the reader.
> or, even better:
>
> g) a rather simple mechanism of POST-constructors could be
> introduced to SAFELY/MEANINGFULLY exploit the polymorphic
> behavior (publish this, start threads, etc) at "construction"
> time without all those silly "manual" init()s/factories/final
> wrappers, etc.
That would be nice, but it wouldn't help existing code. That probably
needs its own JSR, too.
Jeremy
-------------------------------
JavaMemoryModel mailing list -
http://www.cs.umd.edu/~pugh/java/memoryModel
Joe Seigh
Alexander Terekhov wrote:
>
> Joe Seigh wrote:
...
> > http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&selm=1998Apr7.093117%40bose.com
>
> Uhmm. Do you mean something along the lines of "P.S." stuff
> below? Frankly, I do NOT see any problems... since you need
> to have an appropriate SYNCHRONIZATION protocol to pass
> dynamically created object refs/ptrs/whatever to other
> threads...
>
> > http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&selm=1998Apr8.081242%40bose.com
>
> : It turns out that a new object with all of its fields initialized to
> : their default values is not so very interesting from a programming
> : point of view. Since you'd have to use explicit synchronization
> : anyway to sync the memory state after the init methods have run, the
> : issue of an object's initial memory state doesn't exist for
> : programming. The issue is still a java security or integrity issue
> : however.
>
> http://groups.google.com/groups?as_umsgid=3C8DED28.3154017%40web.de
> http://groups.google.com/groups?as_umsgid=3C8CBE40.4530411B%40web.de
>
> regards,
> alexander.
>
snip
No, nothing of that sort, and nothing that really has an analogy in C++.
And yes, properly threaded programs should be using synchronization in
these kind of situations. Rather, this is specific to java where it guarantees
things that you will not see, e.g. invalid references to something that
is not an object or an object not properly in your space, or more generally
a value that wasn't a default value or one that your program stored. There
is no unitialized storage in java.
The java specification did not explicitly address this issue.
Joe Seigh
Alexander Terekhov
Joe Seigh wrote:
[...]
> No, nothing of that sort, and nothing that really has an analogy in C++.
> And yes, properly threaded programs should be using synchronization in
> these kind of situations. Rather, this is specific to java where it guarantees
> things that you will not see, e.g. invalid references to something that
> is not an object or an object not properly in your space, or more generally
> a value that wasn't a default value or one that your program stored. There
> is no unitialized storage in java.
So, "stale-object-state" garbage is MUCH BETTER
(more useful/safe) garbage than C/C++-style "undefined"
garbage?! Sorry, but I just can't comprehend it!
Perhaps you could help me...
regards,
alexander.
Joe Seigh
You lost me there. Afraid I can't help you out.
Joe Seigh
Alexander Terekhov
I just do not see much value in "not-out-of-thin-air
safety"[1]. After all, it does NOT transform (by some
magic) a broken program into some LESS broken program,
AFAICT.
And what does these all have to do with "security
manager/access rights" is COMPLETELY beyond my
understanding; see "4 Safety guarantees":
http://www.cs.umd.edu/~pugh/java/memoryModel/semantics.pdf
regards,
alexander.
[1] "The exception to this is that incorrectly
synchronized reads of non-volatile longs and
doubles are not required to respect the 'not
out of thin air' rule (see Section 8.8 for
details)."
Hillel Y. Sims
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3C9236F3...@web.de...
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/semantics.pdf
>
Something curious caught my eye... This paper states in section 4.1:
------
(figure 1a:)
initially: p = &x; x = 1; y = -1
thread 1 --> y = 2; MemBar; p = &y;
thread 2 --> r1 = p; r2 = *r1
Could result in r2 = -1
Consider execution of the code on the left of Figure 1a on a multiprocessor
with a weak memory model (all of the ri variables are intended to be
registers that do not require memory references). Can this result in r2
= -1? For this to happen, the write to p must precede the read of p, and the
read of *r1 must precede the write to y.
[...]
Given that the instructions in thread 1 cannot be reordered, you might think
that the data dependence in thread 2 would prohibit seeing r2 = -1. You'd be
wrong. The Alpha memory model allows the result r2 = -1. Existing
implementations of the Alpha do not actually reorder the instructions.
However, some Alpha processors can fulfill the r2 = *r1 instruction out of a
stale cache line, which has the same effect. Future implementations may use
value prediction to allow the instructions to be executed out of order.
------
This seems to imply Alphas are fundamentally flawed? Am I missing something?
When they say "some Alpha processors" are they simply referring to old-model
chips (we have newest EV6 level cpus in our machines)? Anyone have any
thoughts on this?
thanks,
Hillel Y. Sims
hsims AT factset.com
Alexander Terekhov
If you think that your EV6es are "fundamentally flawed" I would
be quite happy to get one or two of your EV6 systems and replace
it with some IA64's real-junk (e.g. Dell-made beasts, recently
pulled off the Net-shelves... due to "low" demand). ;-)
On a slightly more serious note, I think that it
has nothing to do with "reorder the instructions".
Basically, without PROPER sync, "MemBar" in thread 1
may have NO effect whatsoever (with respect to memory
coherency view) on thread 2; hence thread 2 could
"read"/see some "not-out-of-thin-air"-BUT-TOTALY-
WRONG-NEVERTHELESS value -- "-1", in this case...
that is how I see it, anyway.
You may want to take a look at these papers too:
http://rsim.cs.uiuc.edu/~sadve/Publications/models_tutorial.ps
http://www.primenet.com/~jakubik/mpsafe/MultiprocessorSafe.pdf
regards,
alexander.
Hillel Y. Sims
> > initially: p = &x; x = 1; y = -1
> > thread 1 --> y = 2; MemBar; p = &y;
> > thread 2 --> r1 = p; r2 = *r1
> > Could result in r2 = -1
>
> be quite happy to get one or two of your EV6 systems and replace
> it with some IA64's real-junk (e.g. Dell-made beasts, recently
> pulled off the Net-shelves... due to "low" demand). ;-)
>
4x8x1GHz GS320s... running OpenVMS 7.3 eh... I'd like to try Tru64, but I
can't convince the powers that be. Hmm... I wonder how much a personal
development alpha costs... Tru64 unix has a much better C++/threads
implementation than solaris ;-)
> On a slightly more serious note, I think that it
> has nothing to do with "reorder the instructions".
> Basically, without PROPER sync, "MemBar" in thread 1
> may have NO effect whatsoever (with respect to memory
> coherency view) on thread 2; hence thread 2 could
> "read"/see some "not-out-of-thin-air"-BUT-TOTALY-
> WRONG-NEVERTHELESS value -- "-1", in this case...
> that is how I see it, anyway.
>
ok, so if I understand what is the case in this situation is that the -1
result is not even necessarily the -1 that was in y originally...
thread2:r1=p might be reading the value of p during the time while it is in
an inconsistent state being written (non-atomically) by thread1:p=&y, so it
may actually point to random location which just happens to coincidentally
contain (r2=*r1) == -1 and not actually related to the -1 that was in y at
the start?
> You may want to take a look at these papers too:
>
> http://rsim.cs.uiuc.edu/~sadve/Publications/models_tutorial.ps
> http://www.primenet.com/~jakubik/mpsafe/MultiprocessorSafe.pdf
>
I read the mpsafe one, it's pretty good - going to print out a copy at work
on Monday.
> regards,
> alexander.
thanks,
hys
Joe Seigh
Alexander Terekhov wrote:
>
> Joe Seigh wrote:
> >
> > Alexander Terekhov wrote:
> > >
...
> > > So, "stale-object-state" garbage is MUCH BETTER
> > > (more useful/safe) garbage than C/C++-style "undefined"
> > > garbage?! Sorry, but I just can't comprehend it!
> > > Perhaps you could help me...
> > >
> > You lost me there.
>
> I just do not see much value in "not-out-of-thin-air
> safety"[1]. After all, it does NOT transform (by some
> magic) a broken program into some LESS broken program,
> AFAICT.
>
> And what does these all have to do with "security
> manager/access rights" is COMPLETELY beyond my
> understanding; see "4 Safety guarantees":
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/semantics.pdf
>
> regards,
> alexander.
>
> [1] "The exception to this is that incorrectly
> synchronized reads of non-volatile longs and
> doubles are not required to respect the 'not
> out of thin air' rule (see Section 8.8 for
> details)."
Well, one problem possibly is that java semantics are both a specification and a
meta-implementation. That is a really bad idea for a number of reasons. One is,
you never see the real semantics. The specification's authors had to work everything
out in their heads and could always realize later that they made a mistake and then
say "oops" and how would you know. You always though it was "working as designed".
Another is it confuses things sometimes. It's not always clear whether you are
talking about the specification or an implementation.
Anyhow, the issue has to do with whether the meta-implementation deals with security
and integrity specifications correctly, not with programming correctly.
To make an analogy, suppose the unix storage manages didn't have the proper memory
barriers when allocating reclaimed storage from other threads or processes. You
would have the possibility of late stores from that other thread or process causing
problems with the newly allocated memory. Nobody would claim this is a programming
issue and not a bug in the implemtation.
Joe Seigh
Alexander Terekhov
"Hillel Y. Sims" wrote:
[...]
> > On a slightly more serious note, I think that it
> > has nothing to do with "reorder the instructions".
> > Basically, without PROPER sync, "MemBar" in thread 1
> > may have NO effect whatsoever (with respect to memory
> > coherency view) on thread 2; hence thread 2 could
> > "read"/see some "not-out-of-thin-air"-BUT-TOTALY-
> > WRONG-NEVERTHELESS value -- "-1", in this case...
> > that is how I see it, anyway.
> >
>
> ok, so if I understand what is the case in this situation is that the -1
> result is not even necessarily the -1 that was in y originally...
> thread2:r1=p might be reading the value of p during the time while it is in
> an inconsistent state being written (non-atomically) by thread1:p=&y, so it
> may actually point to random location which just happens to coincidentally
> contain (r2=*r1) == -1 and not actually related to the -1 that was in y at
> the start?
That is basically how it "works" in POSIX (it has no
"atomicity" guarantees with respect to any non-synchronized
writes), AFAICT. And I'm still struggling to understand
what Java's extra "safety" is all about! :-(
regards,
alexander.