Re: mt questions

[shashank <sha...@gm...>]

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 <vtz...@gm...> 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 <sha...@gm...> 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 <vtz...@gm...>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
>>>
>>
>>
>