Win a copy of Transfer Learning for Natural Language Processing (MEAP) this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Paul Clapham
  • Devaka Cooray
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Liutauras Vilda
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Piet Souris
Bartenders:
  • salvin francis
  • Carey Brown
  • Frits Walraven

What does "thread safe" mean?

 
Ranch Hand
Posts: 151
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My murach Java book keeps using the term "Thread Safe"  
What does this mean?
Thanks,
Kevin
 
Bartender
Posts: 2550
120
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 ?
 
kevin Abel
Ranch Hand
Posts: 151
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
kevin Abel
Ranch Hand
Posts: 151
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 68899
275
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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

You have read that part wrongly. Regard AWT display components as obsolete.
 
Saloon Keeper
Posts: 21960
149
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Campbell Ritchie
Marshal
Posts: 68899
275
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
kevin Abel
Ranch Hand
Posts: 151
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
salvin francis
Bartender
Posts: 2550
120
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 !!
     
    Sheriff
    Posts: 7051
    184
    Eclipse IDE Postgres Database VI Editor Chrome Java Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    For just incrementing and decrementing you could use AtomicInteger or AtomicLong.
     
    Sheriff
    Posts: 15519
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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.
     
    Greenhorn
    Posts: 23
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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....  
     
    Junilu Lacar
    Sheriff
    Posts: 15519
    263
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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.
     
    Tim Holloway
    Saloon Keeper
    Posts: 21960
    149
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Roses are red, violets are blue. Some poems rhyme and some don't. And some poems are a tiny ad.
    Two software engineers solve most of the world's problems in one K&R sized book
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
      Bookmark Topic Watch Topic
    • New Topic