What does "thread safe" mean?

My murach Java book keeps using the term "Thread Safe"  
What does this mean?
Thanks,
Kevin

kevin Abel wrote:My murach Java book keeps using the term "Thread Safe"  
What does this mean?...

Has the book defined that phrase ? if yes, What is your understanding about the book's explaination ?

Salvin,
I looked in the table of contents and it is not listed.  
The next time I run into it in the book I will come back to CodeRanch.
I appreciate the response.
Thanks,
Kevin

I found some others asking about "thread safe" in Code Ranch.  It has something to do with multiple threads accessing the same classes.  Also something about AWT being newer than the old GUI thing. I'm not using multi-threading so I think I can learn about this later on.

kevin Abel wrote:. . . AWT being newer than the old GUI thing. . . .

You have read that part wrongly. Regard AWT display components as obsolete.

kevin Abel wrote:I found some others asking about "thread safe" in Code Ranch.  It has something to do with multiple threads accessing the same classes.

Nope. It has everything to do with how multiple threads access the same resources. The shared resource may be a class or a component of a class. If the access to that resource is controlled (via Java synchronization), then it's (probably) thread-safe.

AWT does have some utility still, I think, but it's dead last when considered for use as a desktop GUI. It's slower and less efficient than Swing, uglier, and less able to integrate well into the machine's underlying windowing/GUI system.

The reason why I hesitate to pronounce AWT as dead is I'm fairly sure that there are parts of Swing that do build on AWT.

And, incidentally, there are alternatives to both, despite the fact that AWT and Swing are part of the core JRE (at least before Oracle started partitioning it). The Eclipse IDE was built on a third-party GUI framework called SWT and it's not the only major GUI product to be developed so.

Tim Holloway wrote:. . . AWT does have some utility still . . . there are parts of Swing that do build on AWT. . . .

The non‑display AWT classes include Color, layout managers, and listeners, and they are all still in regular use with Swing®. Many Swing® display classes are subtypes of AWT classes, too.

Campbell,
Yes you are right.  Swing is the newer thing.  AWT is the older one.
Tim,
It reminds me of the old days of my dBase programming where two PCs running the same software were attempting to write to the same cell in a table.  They were sort of like threads but from two different machines.
Appreciation to all.
Thanks,
Kevin

When multiple threads are involved, even doing a simple task such as incrementing a number gets tricky. Basically, if there's any object that can be accessed by two or more threads and if that object allows it's data to be changed, we're in a soup  

Possible solutions to overcome this :

Dont share objects (not practical)

Ensure shared objects cannot change their data (Immutable)

"Put a lid over it". (My favorite solution. Simply add a disclaimer that your library or code is not "Thread safe".)

Add locks. (This involves using synchronized code blocks, synchronized methods, double checking etc...)

Point 4. above needs a lot of thought process and may not always be the right solution and can cause other problems like deadlocks, starvation and the worst of all: Performance.
Sometimes there's no right solution !!

For just incrementing and decrementing you could use AtomicInteger or AtomicLong.

kevin Abel wrote:
It reminds me of the old days of my dBase programming where two PCs running the same software were attempting to write to the same cell in a table.  They were sort of like threads but from two different machines.

You're aging yourself and so will I now. One of the first environments I did non-trivial programming in was dBase—II, III, IV, and xBase (FoxBase, FoxPro, and my favorite at the time, Clipper)—and yes, thread-safety issues are very similar to what you mentioned. Immutable classes are inherently thread-safe because once created their state won't change. Anything that is mutable should be examined and tested carefully for thread safety if there's a chance it will be used in a multithreaded environment. Essentially, it boils down to maintaining and using shared state in a way that preserves the integrity of data and logic.

About the term "thread-safe" ::   I think it means that if a running piece of code is executing normally,  and it needs to create a new separate thread to perform a separate task,   ( like updating some remote data access,  then the new threads is not allowed to disrupt any other thread that may be accessing the same resource.  The disruption could cause data to be lost or distorted if two different treads tried to do an update operation at the same time.  "Thread-safe"  code protects against that....  

Andrew Jerpe wrote:I think it means that if a running piece of code is executing normally,  and it needs to create a new separate thread to perform a separate task,   ( like updating some remote data access,  then the new threads is not allowed to disrupt any other thread that may be accessing the same resource.  The disruption could cause data to be lost or distorted if two different treads tried to do an update operation at the same time.  "Thread-safe"  code protects against that....

This seems like a valid scenario but it's also a very specific example. Thread-safety in general covers way more scenarios than this.

It's also worth noting that thread are intra-JVM constructs and are only one form of multi-tasking. You can also have multiple OS processes, you can have multiple CPU cores (tightly-coupled multi-processing), multiple-CPU motherboards and multiple physical machines (loosely-coupled multi-processing).

Take DBase. With a few exceptions DOS was not a multi-tasking OS, but if a DBase or FoxPro database was on a shared fileserver (say, a Novell LAN), then there was a potential for corruption and/or denial of service. That's because the only level of resource locking available was at the file level - when it was employed at all and there was no central monitor to ensure that the different users were informed when what was in their local buffers was stale info because someone else had altered the file. That's not threading at all. It's multi-processing at the loosest level.

Java's "synchronized" features apply only to threads within the current JVM. Anything requiring co-ordination at any larger scope - including between 2 different JVMs - requires other mechanisms.

Tim Holloway wrote:That's because the only level of resource locking available was at the file level - when it was employed at all and there was no central monitor to ensure that the different users were informed when what was in their local buffers was stale info because someone else had altered the file. That's not threading at all. It's multi-processing at the loosest level.

Java's "synchronized" features apply only to threads within the current JVM. Anything requiring co-ordination at any larger scope - including between 2 different JVMs - requires other mechanisms.

Also:

Nope. It has everything to do with how multiple threads access the same resources. The shared resource may be a class or a component of a class. If the access to that resource is controlled (via Java synchronization), then it's (probably) thread-safe.

I'm looking back at this 3 years later.   I'm not sure about what a JVM resource is.   I'm thinking of it as a Class or method.   Is the idea that two parts of the code cannot change the values of something in them?   The code might even be running on more than one JVM.    I didn't know that a second JVM could see the objects from another JVM.  

Thanks,

Kevin

When I say "resource", I mean stuff like a specific variable instance, an I/O provider (file, network connection, or whatever) or even other threads. Basically anything that you can do something with.

JVMs cannot access each other's memory, threads, or other internal resource, but they can share external resources, like when 2 different Java apps want to write to the same file at the same time. However "synchronized" access doesn't cover that. Stuff that's declared synchronized is only guarded against concurrent access by other threads in the same JVM. To synchronize with other OS proccesses (JVMs or otherwise) requires OS synchronization services, which may not be avaiable to pure Java code.

I make a simple semaphore. A simple bool or int. This is a simple gate.
A thread can only do something when the gate is open. Say sem=1.
If sem==0 the thread simply waits.
So if sem==0 then FIRST you close the gate. Make sem 1.
THEN you do the work. If the work is ready, then as last action you open the gate.
Works perfect.
Important thread you use pauses of say 20 msec
A not important thread, for example show internet loaded value in a gui field, you use pauses
Of say 500 msec.
Works perfect.

Sorry for writing error in my semaphore text. I swapped the values 0 and 1 .
So for example you make a common basket , protected by a common semaphore.
The important high speed,  http thread fills the http received value in the basket.
The less important, slower , thread takes this value out the basket and shows it in the
Gui field.
Between closing the gate and the code for the action it is possible, that the cpu divide the code....!!! But Java has a simple solution: set closing the gate and the action simply in one not dividable code block.
Baron