* CVS User nsiivola [2011-06-18 11:51] writes:
Update of /project/slime/cvsroot/slime In directory common-lisp.net:/tmp/cvs-serv20168
Modified Files: ChangeLog swank.lisp Log Message: swank: lock around updating the indentation cache
Hash-tables aren't necessarily thread safe. (Yes, I actually saw the table get corrupted -- this isn't just theoretical.)
Please, don't use locks in swank.lisp.
Helmut
On 18 June 2011 17:33, Helmut Eller heller@common-lisp.net wrote:
Please, don't use locks in swank.lisp.
Ok. Which of the following do you prefer:
1. Keep the locks, but move the indentation cache out of swank.lisp?
2. Add a defimplementation for make-hash-table* and &co?
3. Roll our own hash-table lookalike that's safe?
Cheers,
-- nikodemus
* Nikodemus Siivola [2011-06-18 14:46] writes:
On 18 June 2011 17:33, Helmut Eller heller@common-lisp.net wrote:
Please, don't use locks in swank.lisp.
Ok. Which of the following do you prefer:
Keep the locks, but move the indentation cache out of swank.lisp?
Add a defimplementation for make-hash-table* and &co?
Roll our own hash-table lookalike that's safe?
4. Use a separate thread, keep mutable object local to thread, communicate with message passing
Helmut
On 18 June 2011 19:37, Helmut Eller heller@common-lisp.net wrote:
- Use a separate thread, keep mutable object local to thread,
communicate with message passing
Does this seems appropriate?
https://github.com/nikodemus/Slime/commit/95a8e07535f985005519dfb6bc4bbc9bcf...
Cheers,
-- Nikodemus
* Nikodemus Siivola [2011-06-19 10:05] writes:
On 18 June 2011 19:37, Helmut Eller heller@common-lisp.net wrote:
- Use a separate thread, keep mutable object local to thread,
communicate with message passing
Does this seems appropriate?
https://github.com/nikodemus/Slime/commit/95a8e07535f985005519dfb6bc4bbc9bcf...
Is it necessary to run this in the control-thread? Can't you just create a separate thread for this?
Helmut
On 19 June 2011 18:24, Helmut Eller heller@common-lisp.net wrote:
Is it necessary to run this in the control-thread? Can't you just create a separate thread for this?
Not /necessary/, but since control-thread will anyways be the one responsible for sending the update, adding a new per-connnection thread just for this is seemed like shooting a fly with a cannon.
I can do that though. Are there any other housekeeping tasks that could/should be delegated to such a thread?
Cheers,
-- nikodemus
* Nikodemus Siivola [2011-06-19 17:04] writes:
On 19 June 2011 18:24, Helmut Eller heller@common-lisp.net wrote:
Is it necessary to run this in the control-thread? Can't you just create a separate thread for this?
Not /necessary/, but since control-thread will anyways be the one responsible for sending the update, adding a new per-connnection thread just for this is seemed like shooting a fly with a cannon.
The control-thread is not the place to do unimportant things.
I can do that though. Are there any other housekeeping tasks that could/should be delegated to such a thread?
Do one task per thread.
Alternatively you also copy the cache, update the copy, and finally store the copy with a single setf into the shared location. That would be thread safe enough.
Helmut
On Mon, 20 Jun 2011 09:02:40 +0200, Helmut Eller said:
Alternatively you also copy the cache, update the copy, and finally store the copy with a single setf into the shared location. That would be thread safe enough.
I think that strategy requires memory barriers for safety.
__Martin
* Martin Simmons [2011-06-20 12:01] writes:
On Mon, 20 Jun 2011 09:02:40 +0200, Helmut Eller said:
Alternatively you also copy the cache, update the copy, and finally store the copy with a single setf into the shared location. That would be thread safe enough.
I think that strategy requires memory barriers for safety.
Read-after-write consistency is not needed in this case. The next thread will recognize that his copy is obsolete and will compute the same result. No harm done; just some redundant computations.
Helmut
SHould fixed to everyone's satisfaction in CVS HEAD.
Cheers,
-- nikodemus