Locking data

IntegratedDimensions IntegratedDimensions at gmail.com
Wed May 23 02:11:03 UTC 2018


On Tuesday, 22 May 2018 at 23:09:24 UTC, Sjoerd Nijboer wrote:
> On Tuesday, 22 May 2018 at 22:17:05 UTC, IntegratedDimensions 
> wrote:
>> On Tuesday, 22 May 2018 at 22:10:52 UTC, Alex wrote:
>>> On Tuesday, 22 May 2018 at 21:45:07 UTC, IntegratedDimensions 
>>> wrote:
>>>> an idea to lock data by removing the reference:
>>>>
>>>> class A
>>>> {
>>>>    Lockable!Data data;
>>>> }
>>>>
>>>> The idea is that when the data is going to be used, the user 
>>>> locks the data. The trick here is that data is a pointer to 
>>>> the data and the pointer is set to null when locked so no 
>>>> other data can use it(they see a null reference). To unlock, 
>>>> the data is reassigned:
>>>>
>>>> auto d = data.lock(); // A.data is now null deals with sync 
>>>> issues
>>>> //use d
>>>> d = data.unlock(d); // restores A.data (A.data = d;) and 
>>>> sets d to null so any future reference is an error(could 
>>>> produce bugs but should mostly be access violations)
>>>>
>>>>
>>>> Anyone else trying to use data will see that it is null 
>>>> while it is locked.
>>>>
>>>> This basically pushes the standard locking mechanisms in to 
>>>> the Lockable!data(first come first serve) and code that has 
>>>> not captured the data see's it simply as null.
>>>>
>>>> Anyone use know if there exists an idiom like this and what 
>>>> it is called? Maybe some idiomatic code that is efficient?
>>>>
>>>>
>>>> Ideally I'd want to be able to treat the Lockable!Data as 
>>>> Data. Right now I have to classes(or pointers to structs) 
>>>> and few weird hacks. I think what I'll have to end up doing 
>>>> is having a Locked!Data structure that is returned instead 
>>>> or use an UFCS. The idea being to attach the lock and unlock 
>>>> methods.
>>>
>>> Are you aware of NullableRef?
>>> https://dlang.org/library/std/typecons/nullable_ref.html
>>>
>>
>> Yes.
>>
>>> Does it fit somehow?
>>
>> Not really. It could be used to wrap the data when used as a 
>> struct but it offers none of the locking features which is the 
>> ultimate goal.
>>
>> The idea is simply that one can lock the data to get exclusive 
>> access. Normally standard locking tricks are used but in this 
>> case the idea is to do all that behind the scenes. Locking the 
>> data makes all other accessors see null data(and crash or 
>> properly test). This is a first come first serve or single 
>> access type of pattern but sort of removes the data from 
>> prying eyes while it is being used.
>
> how about something like
>
>  import core.atomic;
>  class Lockable!Data
>  {
>     private __gshared Lockable!Data data;
>  }
>
>  struct Locked!Lockable!Data
>  {
>     private TailShared!Lockable!Data lockedData;
>     private Lockable!Data lockableData;
>
>     this(Lockable!Data lockableData)
>     {
>         this.lockableData = lockableData;
>         while( (lockedData= atomicLoad(lockableData)) !is null)
>             if(cas(lockedData, lockedData, null))
>                 break;
>     }
>
>     ~this()
>     {
>         atomicStore(lockedData, lockableData );
>     }
>
>     alias lockedData.data this;
>  }
>
> With something like this you should be able to do RAII like 
> semantics on your data.
> You share a Lockable!Data which you want use, and then you can 
> access it if you instantiate a Locked!Lockable!Data struct with 
> it.
> FYI, my atomics isn't all that great so don't expect this to 
> work.

This is similar to what I am doing... maybe "identical".


More information about the Digitalmars-d-learn mailing list