aspose file tools*
The moose likes Threads and Synchronization and the fly likes How to block access based on elements existance? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "How to block access based on elements existance?" Watch "How to block access based on elements existance?" New topic
Author

How to block access based on elements existance?

Justin Thomas
Ranch Hand

Joined: Mar 08, 2012
Posts: 62
String uid = HardDrive_UUID.intern();

Whyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy didn't you tell me intern was needed? You would have saved your time as well as mine.....


---
ps: You gave 3 possible reasons, not "those 3 or maybe smth else". If I pursued all of your so-called possibilities I would have wasted another couple hours. And one more thing: it's fair to expect from someone with thousands of posts to know about String Pool (which now looks to me as great simple and effective idea, once I heard about it), so there is only one possible logical reason why: Malevolent purpose!
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Justin Thomas wrote:
Henry Wong wrote:
Not the hashcode. The *identity* hashcode. You can get it from the java.lang.System class.

Henry


Did the correct one this time.
Hashcode for above: 219987657
Hashcode for above: 1942571857

But it was said previously in this thread that the lock is based on value not on reference - and the value is the same. Why doesn't it work... ffs.

Object 1 in Thread 1:
Gathers data
Gathers also UUID string
Sends data + uuid to that static method above

Object 2 in Thread 2:
Gather data
Gathers also UUID
Sends data + uuid to that static method above

And those uuids are the same!!! I wasted in total 8 hours trying to make a simple conditional synchronization.... come on.... why it the hell doesn't work!!!


Please calm down. I think you're over-complicating things, and probably trying to bite of more than you can chew before understanding how Java's multithreading works.

At this point, I think you should take a step back, and approach this in smaller pieces. Start with a simple 2-threaded program where one thread simply adds to a Collection and another simply removes from it. You can use Thread.sleep() to insert some artificial delays so that you don't have to worry about wait() and notify(). Once you get that working, get rid of the sleep() calls and add wait() and notify() to your loops. Once that works, put some sleep() calls back in, to force various timings of one thread or the other starting first, and of data arriving or being pulled out. And so on.

Once you've got that simple producer/consumer working and you understand it, then you can start thinking about your problem. But don't initially think in terms of synchronized, wait(), and notify(). Think in terms of which resources need to be accessed by only one task at a time, and which operations need to be executed atomically. Once you have a good grip on that, it will be easier to turn it into the specific Java realizations of those concepts.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Justin Thomas wrote:String uid = HardDrive_UUID.intern();

Whyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy didn't you tell me intern was needed? You would have saved your time as well as mine.....


Please don't shout.

It's definitely NOT needed. It might be ONE valid approach, or it might be a total hack that works, or it might be that it doesn't really work, but you're just getting lucky in your testing so far.

If you are convinced that it is a valid approach, then you should be able to explain why.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Justin Thomas wrote:
ps: You gave 3 possible reasons,


Yes, and I stand by that.

not "those 3 or maybe smth else".


It wasn't "something else". If this is indeed a valid solution, then it means that you were making an error with your mutex, which is one of the reasons I gave.

If I pursued all of your so-called possibilities I would have wasted another couple hours.


No. If you did it right, you would have either been able to quickly rule out a couple of possibilities, or you would have spent a couple of hours learning something.

And one more thing: it's fair to expect from someone with thousands of posts to know about String Pool


I do know about it. I don't know enough about the details of your problem to know if it's an appropriate solution though. However, I do believe I mentioned "reference equality," which is exactly what the String pool gives you.

so there is only one possible logical reason why: Malevolent purpose!


Sure, go for it. If it makes you feel better to believe that I spent all that time just trying to mess with your head rather than examine the possibility that maybe your explanations of your problem weren't very clear or that you need more work on the fundamentals of Java in general and multithreading in particular, knock yourself out. It's no skin off my nose.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18990
    
  40

Justin Thomas wrote:
Henry Wong wrote:
Not the hashcode. The *identity* hashcode. You can get it from the java.lang.System class.

Henry


Did the correct one this time.
Hashcode for above: 219987657
Hashcode for above: 1942571857

But it was said previously in this thread that the lock is based on value not on reference - and the value is the same. Why doesn't it work... ffs.


The lock is *not* based on value or reference. It is based on objects. The threads have to use the same object -- and two different string objects with the same value is not the same thing.

Henry
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18990
    
  40

Jeff Verdegan wrote:
Justin Thomas wrote:String uid = HardDrive_UUID.intern();

Whyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy didn't you tell me intern was needed? You would have saved your time as well as mine.....


Please don't shout.

It's definitely NOT needed. It might be ONE valid approach, or it might be a total hack that works, or it might be that it doesn't really work, but you're just getting lucky in your testing so far.

If you are convinced that it is a valid approach, then you should be able to explain why.



The reason interning works is because it stores the string in the stringpool -- and the string pool will guarantee that there is only one copy of a value of a string in the pool. Unfortunately, it also has other effects. The other effect being that it is now in the string pool, and hence, never eligible for garbage collection. This means that your UUID code -- as you keep using it -- will keep using more memory. For short live transactions, that generate different strings per transaction, this is effectively a memory leak.

Henry
Justin Thomas
Ranch Hand

Joined: Mar 08, 2012
Posts: 62
Jeff Verdegan wrote:
Justin Thomas wrote:so there is only one possible logical reason why: Malevolent purpose!


Sure, go for it. If it makes you feel better to believe that I spent all that time just trying to mess with your head


You did.


-----
Concerning the subject: For future adnotations and people who use "Search" and find it the moral is this: No one will solve a problem for you; You must do it yourself.

//end of Thread.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18990
    
  40

Justin Thomas wrote:
Jeff Verdegan wrote:
Justin Thomas wrote:so there is only one possible logical reason why: Malevolent purpose!


Sure, go for it. If it makes you feel better to believe that I spent all that time just trying to mess with your head


You did.


-----
Concerning the subject: For future adnotations and people who use "Search" and find it the moral is this: No one will solve a problem for you; You must do it yourself.

//end of Thread.



Justin,

I don't normally like to comment on these side discussions -- but this one seems to get heated. At the end of the day, Jeff did try to help you, and it may be a good idea to assume that Jeff has more good intentions than bad intentions.

Henry
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Henry Wong wrote:
The lock is *not* based on value or reference. It is based on objects. The threads have to use the same object -- and two different string objects with the same value is not the same thing.


Henry Wong wrote:
The reason interning works is because it stores the string in the stringpool -- and the string pool will guarantee that there is only one copy of a value of a string in the pool.


@Justin: I hope Henry's excellent explanations here will prevent you from adding a factoid like "If you're going to sync on a String, you have to intern it first" to your understanding of Java multithreading. Synchronization always works in the same, simple fashion, with no weird corner cases like that.

As it turns out, you'll probably rarely if ever sync on a String. Not because they're special in some way as far as syncing is concerned, but just because when you go through the reasons of which object to choose to sync on, they'll probably rarely or never lead you to a String. And we can see from Henry's comments why they weren't a good choice here.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Justin Thomas wrote:
Concerning the subject: For future adnotations and people who use "Search" and find it the moral is this: No one will solve a problem for you; You must do it yourself.


Absolutely correct. The purpose of this site isn't to solve people's problems for them, but to guide them toward the understanding they need to solve them on their own. That's what we tried to do in this thread, whether you choose to believe that or not.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to block access based on elements existance?