Udham Singh

Hello Everybody!

I haven't posted here in a long time but I was wondering if anybody knew what makes one get the infamous 44/80 score on locking. These where my scores.

General Considerations (maximum = 100): 99
Documentation (maximum = 70): 70
O-O Design (maximum = 30): 30
GUI (maximum = 40): 31
Locking (maximum = 80): 44
Data store (maximum = 40): 40
Network server (maximum = 40): 40

If it is against the rules to disuss this then can somebody at least give me a hint. I thought my solution was perfect.


Thanks in advance

Andrew,

Is there any straight forward way of determining that?
The reason I wanted to check for waiting threads was because they indicate a locked resource. Of course, just because there are no threads waiting doesn't mean the resource is available and thanks for pointing that out to me.

But still, since there is one lock per record how would one know if the lock is availble or not without first acquiring it?

I guess now my question would be is there anything in the language itself (or API) that lets you do that? Or can you think (or know) of a way around this problem i.e. determing if the resourse is locked/unlocked without acquiring the lock.

Thanks

Hello Andrew !

I have a question about the second solution. I thought of it too but couldn't think of a way to implement isLocked(). Is there a way in Java for one thread to know if there are other threads waiting on a particular object?

If yes could you please tell me how or point in the right direction.

I've already implemented the first solution (the one that wastes CPU cycles). Hopefully I won't it be penalized too much for it.

Thanks !

Thanks Peter !

I'll check it out. I've started implementing Data in the non-OO way so I dont know how much I would change it.

I think implementing caching is very unnecissary. It is a complex problem in its own right. I would love to know what your replacement (paging) policy is But even the simplest solution is way beyond the requirements for this project.

The db file given to us is extremely small. We dont provide anything in the GUI to let the DB to grow either. If the client expects the DB to grow considerably he should probably try to get an actual Database.

For the file given to us the OS is probably going to cache it to some extent I really wouldn't bother caching it again.

But again. I would love to listen to some of the arguments in favour of a caching mechanism in our code.

Please let me know what you have in mind. Maybe I am missing something.

Hey Peter !

I am sure there is nothing drastically different in my spec. I just thought it would be more OO to have a class called Record. And then have instances of that class read/written to the file. It keeps the code neat and clean.

Here is what I am trying.

class Record implements Serializable {
byte[] name;
byte[] specialties;
// yada yada

}

And then just so simple stuff like,

ObjectInputStream ois = new ObjectInputStream(
new FileInputStream("dbFile"));

Record record = (Record) ois.readObject();


I am sure somebody before me must have wanted to be just as lazy so I was wondering where to start looking in the API to do what I am trying to do.

Also I am aware that I can do this,

Record[] records = (Record[]) ois.readObject();

And then access whatever I want. But ofcourse there is Info section at the start of our DB which is not a mulitple of the record length.

For all that got to the end of this post. Thanks for the patience. Please ignore any silly mistakes in my code. I just wanted to explain what I have in mind.

Hello Everybody !

Is there any way I can read/write Objects in the db file at random locations. ObjectInputStream has no seek() method. RandomAccessFile has no readObject() method. Can anybody help me out with problem?

Thanks

I agree with you. But as you yourself said "Smaller the better." Maybe just synchronizing on lock, unlock & isLocked is not such a bad idea. But synchronizing every method in the Data class (as Anton has suggested) seems to be a pretty big lock.

Comments.

Hello Everybody !


I am just looking for good ideas/suggestions on testing multi-threaded code. I think I have a decent locking mechnanism ready but want to test it vigorously before going any further. Is there any good literature already out there on testing deadlocks, starvation, race conditions etc.

Ofcourse personal experiences (& lessons learnt) on testing locking would be greatly appreciated.

Thanks

Vinay,

Why does he want his method to be synchronized? I've done multi-threaded programming only in C and well I am not sure if I understand synchronized methods all that well. But here is what I am thinking. Say threads I and II want to lock records 142 & 137 respectively. Synchronizing the method will make make one wait for the other unnecessarily. Wouldn't you want them to these two threads to acquire the locks concurrently?

Thanks

Sorry about that !

Didn't mean to break any rules.


Udham

Hello Javini !


Thanks for letting me know that there is nothing wrong with my specification. I guess I'll implement the methods anyways. Its not that much work. I wont be propogating these features on the GUI in anyway though.

Thanks once again.

In my assigment I "must" implement an interface DBMain with these method signatures.
public void delete(int recNo) throws RecordNotFoundException;
public int create(String[] data) throws DuplicateKeyException;

The trouble is no where in the assignment have I been asked to let the user perform these operations on the data file. I have been asked only to provide for searh functionality on the data file. Should I still provide delete and create (in Data.java and the GUI) or is it okay if just threw UnsupportedOperationException in my code for create and delete.


The reason why I ask is well, the assinment looks like it was generated by a computer so maybe there is something seriously wrong with my specs. Another reason is that Sun expects people to finish this assignment in 20 hrs so I guess they really dont want to see any extra work being implemented.

Please let me know if I have misunderstood something.