synchronization: concurrent method access problem

[Piper707]

Hi,

I have a problem for a bit of code that needs thread synchronization.
The code is something like this:

classA
{
static synchronized getUniqueId()
}

class B
{
A.getUniqueId()
}

I have a class A that contains a static synchronized method that
assigns unique ids. This method gets invoked from a different class
and by multiple threads.

Multiple threads did enter the same method inspite of the synchronized
keyword, and this resulted in the same id being given to different
threads.

I found a post that explains that Two threads can execute the same
synchronized method on
different instances concurrently.

Keeping that in mind, I could think of two options:

1) make class A singleton, so that all the threads try to execute the
same synchronized method on a single instance

2) make class A a static member variable in class B and invoke the
call as it is currently done.

is this the right approach? am I on the right track here?

thanks for any help,
Rohit

 

[Patricia Shanahan]

Hi,

I have a problem for a bit of code that needs thread synchronization.
The code is something like this:

classA
{
static synchronized getUniqueId()
}

class B
{
A.getUniqueId()
}

I have a class A that contains a static synchronized method that
assigns unique ids. This method gets invoked from a different class
and by multiple threads.
>
Multiple threads did enter the same method inspite of the synchronized
keyword, and this resulted in the same id being given to different
threads.

Because it is static, getUniqueId should be synchronized on the class
object for classA. Unless you are using multiple class loaders, that
should be a unique object.

Can you produce a small example of the duplicate id problem?

Patricia

 

[Piper707]

Hi,

here are some more details on the problem:

class A
{

//stores all unique ids generated
private static sortedSet; //this is Collections.synchronized

public static synchronized getUniqueId()
{
//connect to a DB and get the max number of records

//create a unique id as max records + 1;

if(sortedSet contains id)
{
//uniqueId = get largest id in set + 1
}

//add unique id to sorted set

//return the uniqueId

}

class B
{
//A.getUniqueId()

//use this unique id to add an entry in the DB
}


multiple threads invoke this code. I am expecting each thread to get a
unique id. But 2 threads enter my synchronized method and while one of
them gets the id 2, the next one also gets the id 2.

This eventually results in 2 threads trying to put in an entry into
the DB with the same primary key (unique id).

This happens because my check for if (sortedset contains id) FAILS for
the second thread. i.e. before the first thread can put in the unique
id inside the sorted set, the second set does the check to see if that
id exists.

 

[Eric Sosman]

Hi,

here are some more details on the problem:
[... code snipped ...]

When I tried to compile the code you provided,
javac was not too pleased with it:

javac Foo.java
Foo.java:5: <identifier> expected
private static sortedSet; //this is Collections.synchronized
^
Foo.java:7: invalid method declaration; return type required
public static synchronized getUniqueId()
^
Foo.java:13: ')' expected
if(sortedSet contains id)
^
Foo.java:22: illegal start of expression
}
^
Foo.java:17: ';' expected
^
Foo.java:30: '}' expected
^
6 errors

Compilation exited abnormally with code 1 at Fri Nov 16 13:08:03

multiple threads invoke this code. [...]

How do they invoke it if it won't even compile?

You are asking for help in debugging/understanding
a problem with some code. Fine; lots of us are willing
to help. But what you show us is *not* the code that's
giving you trouble! How do you expect anyone to be of
help if you won't provide the facts? [*]

[*] An old acquaintance got caught in just such a
situation. He was dispatched to a customer site to fix
a machine they'd bought, but the customer was a super-
secret agency that wouldn't allow him onto the premises.
He'd sit in a coffee shop across the street and talk with
agency people about things they might try, then they'd
leave and go back into the forbidden zone. After a while
they'd come back and say "It's still not working," but
for security reasons they'd been forbidden to reveal
anything else, not even the outcome of diagnostic tests
and the status of telltale lights ... After about three
days of this (and with an okay from his boss) he finally
told them "It can't be fixed" and went home.