Okay! Great.

> If we have 'real' cas - testandset should be expressed via it - no need to keep both.
> If you are using recent gcc - there is: __sync_val_compare_and_swap. This can be your first attempt at cas - just use it.

Yes, I came across __sync_val_compare_and_swap method. My concern for
asking if we should keep both was since we had to support multiple compilers.
But its clear now. I'll start right away.

Shashank
---
P.S. -
I hate to disappear. But I spent the past 2-3 days without internet connection since it
broke due to some construction near my house.
But everything's back to normal. Good to be online now.


On Mon, May 5, 2014 at 6:19 PM, Vladimir Tzankov <vtzankov@gmail.com> wrote:
testandset is used for spinlock (busy lock) implementation.
spinlock has two states: 0 - not owned, 1 - owned
 
from xthread.d comments:
>> testandset(spinlock) tries to acquire the spinlock. It returns
>> 0 if it succeeded (i.e. the old value was 0, the new one is != 0).
>> It returns != 0 if it failed (i.e. the old value was != 0).

So basically testandset is special case of CAS (testandset(place) == cas(place, 0, 1))

If we have 'real' cas - testandset should be expressed via it - no need to keep both.

If you are using recent gcc - there is: __sync_val_compare_and_swap. This can be your first attempt at cas - just use it.
#define CAS(place, oldval, newval) __sync_val_compare_and_swap((place),(oldval),(newval)) 

However clisp can (and should) be compiled with any c89 compiler. So we need some #ifdefs and asm stuff (like now) for cross platform/compiler support.

In the beginning you can go with gcc specific implementation at the beginning and concentrate entirely on hash table stuff since this is the primary goal of the project. 

Vlad


On Sun, May 4, 2014 at 7:18 PM, shashank <shashankgrovy@gmail.com> wrote:
I love your plan.
Finally the fun begins :D

I'll quickly get on to reading the common lisp and clisp hashtable implementation.Btw just to be clear you're saying, implement cas and use it instead of testandset. Does that mean the existing testandset macros have to go? (i.e. be replaced with cas) or for the new code we should use cas instead of testandset?

Shashank


On Sun, May 4, 2014 at 12:18 PM, Vladimir Tzankov <vtzankov@gmail.com> wrote:
Let's have kind of plan. Here is what i have in mind.

* Study common lisp hashtables (http://www.lispworks.com/documentation/HyperSpec/Body/18_.htm) and clisp implementation in hashtabl.d (there are few extensions to the above standard, e.g. weak relations).
* Study and understand lock free hash table (http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf). Check clozure implementation. IIRC, you will need cas & mutex for this.
* Implement cas and use it instead of testandset. Required mutex implementations are available.
* Start coding and replacing hashtabl.d implementation

Meanwhile you will get common with clisp (some) internals. 

As for you questions:

1. Always use mercurial checkout when consulting code. The link above is to old cvs repo that was not updated for quite some time.
2. win32 condition variables - it will be nice to use native ones but this is not the goal of the project. I would not put too much efforts on this at that stage.
3. There is no need to have 'full grasp' of mutex internals in order to use it. package.d is a place to consult for the usage.

Vlad