FROM : Nathan Day
DATE : Thu Nov 14 01:19:08 2002
On Wednesday, November 13, 2002, at 04:48 PM, Hisaoki Nishida wrote:
> I was mistaken with protected memory. I thought they would eliminate
> things like having to worry about simultaneous write/read from 2
> threads. It only meant protection between application memory bounds.
> The global variable is a struct of type fd_set (struct used in BSD
> sockets). I think it is far larger than 32 bits, it could be 1024
> bits, I'm not sure. I am not familiar with the assembly level detail,
> but I think I should be using an NSLock. I don't really care when my
> main thread writes to the global variable, as long as the 2 threads
> don't do a write and a read at the same time. In fact, I expect my
> main thread to change the variable when it wants to. No other
> restrictions.
> My separate thread is actually a method that handles server logins.
> I feel the need to use a separate thread for this because my main
> thread deals with sends and receives from connected clients. So it
> can't afford to wait for login sessions to be complete (which could
> take long/timeout due to disconnects/lag/other errors).
> I just wanted to know that when you say I need a lock when I only care
> when the variable is changed, do you mean that there is a need to
> regulate when the variable changes so that the read can be performed
> after the write. Then I definitely need a lock, it seems.
If you had some simple variable that represented the number of bytes
received say, and you main thread read this value to display to the
user, then you wouldn't need to worry about any synchronization between
reading and writing, the main thread could read it any time it wanted.
If you want one read to occur after every write then yes you will need
to lock.
Nathan Day
http://homepage.mac.com/nathan_day/
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Thu Nov 14 01:19:08 2002
On Wednesday, November 13, 2002, at 04:48 PM, Hisaoki Nishida wrote:
> I was mistaken with protected memory. I thought they would eliminate
> things like having to worry about simultaneous write/read from 2
> threads. It only meant protection between application memory bounds.
> The global variable is a struct of type fd_set (struct used in BSD
> sockets). I think it is far larger than 32 bits, it could be 1024
> bits, I'm not sure. I am not familiar with the assembly level detail,
> but I think I should be using an NSLock. I don't really care when my
> main thread writes to the global variable, as long as the 2 threads
> don't do a write and a read at the same time. In fact, I expect my
> main thread to change the variable when it wants to. No other
> restrictions.
> My separate thread is actually a method that handles server logins.
> I feel the need to use a separate thread for this because my main
> thread deals with sends and receives from connected clients. So it
> can't afford to wait for login sessions to be complete (which could
> take long/timeout due to disconnects/lag/other errors).
> I just wanted to know that when you say I need a lock when I only care
> when the variable is changed, do you mean that there is a need to
> regulate when the variable changes so that the read can be performed
> after the write. Then I definitely need a lock, it seems.
If you had some simple variable that represented the number of bytes
received say, and you main thread read this value to display to the
user, then you wouldn't need to worry about any synchronization between
reading and writing, the main thread could read it any time it wanted.
If you want one read to occur after every write then yes you will need
to lock.
Nathan Day
http://homepage.mac.com/nathan_day/
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Hisaoki Nishida | Nov 10, 22:58 | |
| Nathan Day | Nov 11, 12:50 | |
| Hisaoki Nishida | Nov 13, 07:18 | |
| Nathan Day | Nov 14, 01:19 |






Cocoa mail archive

