• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking Code

 
Anton Golovin
Ranch Hand
Posts: 527
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, guys!

Have a question about the locking code. This is my locking code:



Basically, everything is clear, except the effect of the continue statement based on who interrupts the thread. Could you give me some advice on what possible variants there are?

Note: As I am testing the lock/unlock, it works quickly with 100 threads but takes a very long time with 1000 threads.

Thanks!
[ August 28, 2004: Message edited by: Anton Golovin ]
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anton Golovin:
Hi, guys!

Have a question about the locking code. This is my locking code:



Basically, everything is clear, except the effect of the continue statement based on who interrupts the thread. Could you give me some advice on what possible variants there are?

Note: As I am testing the lock/unlock, it works quickly with 100 threads but takes a very long time with 1000 threads.

Thanks!

[ August 28, 2004: Message edited by: Anton Golovin ]

Anton,

This is an interesting question.

I think the only likely reason for being interrupted when you wouldn't just continue is when your client is trying to shut down and your server thread is trying to get a lock. If you want to support this case you should provide a way for the server thread to know which client it belongs to and what state that client is currently in. I believe this can be argued to be beyond the scope of this assignment, but in a real world application it would be important since the client should never hang trying to disconnect.

I've been investigating a scheme suggested by Andrew where each client is represented by an instance of the Data class and a SessionManager maps clients to Data instances. As I'm using sockets, I use a long number to identify a session. The client gets a session when it first connects and then provides that in all subsequent commands. I am going to use this to allow the unlocking of records when a client disconnects. It would also help with the decision on whether a wait loop should continue or break.

As I said earlier, this all may be beyond the scope of this project, especially since your locking uses cookies. If it doesn't work or gets too cumbersome, I'll simply put a Design Decision in that says its an enhancement for a later release.

/peter
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic