Re: [Vala] vala friendly atomic pointer
Not the simplest solution, but works well. After thinking more about my problem, I don't think any reliable efficient solution is going to be simple. Thanks for the input. Nice day Nor Jaidi Tuah PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we do not accept liability for any viruses which may be transmitted in or with this message. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala friendly atomic pointer
On Thu, 2013-12-19 at 17:16 +0200, Tal Hadad wrote:
http://www.valadoc.org/#!api=gobject-2.0/GLib.WeakRef
This is a simple solution thanks to the good design of GObject.
Tal
That might not always work, unfortunatly, due to how structs are
implemented[1]. Beside - they are implemented currently using global
lock in GObject[2].
From: norjaidi.t...@ubd.edu.bn
To: vala-list@gnome.org
Date: Thu, 19 Dec 2013 08:59:44 +0800
Subject: [Vala] vala friendly atomic pointer
Dear all,
I want to implement something like these:
* x = AtomicPointer.@get (ref atomicRef) // reader
* AtomicPointer.@set (ref atomicRef, newref) // writer
* return AtomicPointer.@get (ref atomicRef) // reader
but have the benefit of vala ref counting.
The best I can think of is:
* lock (atomicRef) { x = atomicRef; }
* lock (atomicRef) { atomicRef = newref; }
* lock (atomicRef) { return atomicRef; }
But lock is too course.
e.g., lock (atomicRef) {x = atomicRef;} will also lock
out other readers, whereas AtomicPointer.get won't.
I realise that the exclusive region is small.
But if you have a lot of readers, the effect
may be significant.
Any suggestions?
Nice day
Nor Jaidi Tuah
The combination of lock free and reference pointers is 'hard' (as long
as you don't have double word CAS operation which is not implemented on
practically any hardware). The only way I know about is by
HazardPointers.
Gee 0.8 or newer have it's implementation of HazardPointers[3]. The
basic usage is as follows:
MyObject *object_ptr;
MyObject *read_object = HazardPointer.get_pointerMyObject
(object_ptr);
The drawback is that you need to ensure that all operations are in
HazardPointer.Context. You want the context to live in thread as long as
you know that operation is taking place. Upon destruction all pointers
are freed (exact method is specified by policy).
Regards
[1] https://bugzilla.gnome.org/show_bug.cgi?id=703996
[2] https://bugzilla.gnome.org/show_bug.cgi?id=705728
[3] http://www.valadoc.org/#!api=gee-0.8/Gee.HazardPointer
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala friendly atomic pointer
Thanks for the replies. It seems that WeakRef doesn't help with the granularity: multiple readers will lock out each other (I hope I'm wrong here). Besides, from https://bugzilla.gnome.org/show_bug.cgi?id=703996 it appears that WeakRef is totally broken. As for HazardPointers, according to the documentation: HazardPointers are not thread-safe (unless documentation states otherwise) I wish vala has lockread in addition to lock. Nice day Nor Jaidi Tuah PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we do not accept liability for any viruses which may be transmitted in or with this message. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala friendly atomic pointer
On Sat, 2013-12-21 at 11:41 +0800, Nor Jaidi Tuah wrote: Thanks for the replies. It seems that WeakRef doesn't help with the granularity: multiple readers will lock out each other (I hope I'm wrong here). Besides, from https://bugzilla.gnome.org/show_bug.cgi?id=703996 it appears that WeakRef is totally broken. As for HazardPointers, according to the documentation: HazardPointers are not thread-safe (unless documentation states otherwise) I wish vala has lockread in addition to lock. (I've wrote both the HazardPointers and documentations to them) HazardPointers as structure are not thread safe - i.e. you cannot access single HazardPointer from multiple threads. However they do allow multi-thread access (that's their purpose). Best regards signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala friendly atomic pointer
On Sat, 2013-12-21 at 07:08 +0100, Maciej Piechotka wrote: On Sat, 2013-12-21 at 11:41 +0800, Nor Jaidi Tuah wrote: Thanks for the replies. It seems that WeakRef doesn't help with the granularity: multiple readers will lock out each other (I hope I'm wrong here). Besides, from https://bugzilla.gnome.org/show_bug.cgi?id=703996 it appears that WeakRef is totally broken. As for HazardPointers, according to the documentation: HazardPointers are not thread-safe (unless documentation states otherwise) I wish vala has lockread in addition to lock. (I've wrote both the HazardPointers and documentations to them) HazardPointers as structure are not thread safe - i.e. you cannot access single HazardPointer from multiple threads. However they do allow multi-thread access (that's their purpose). Possibly to clarify - I have written the implementation in the Gee, not invent the whole concept[1]. The idea of the whole concept is to access threads is thread safe manner so if it is not clear from documentation it means I need to fix the documentation. With Gee.HazardPointer you have following 'moving parts': - Context(s): Per-thread and organized in a stack. They ensure that memory will be freed even if thread does not call into Gee for a long time while not forcing synchronization at each operation. - HazardPointer: Denotes a pointer in use. They are not thread safe in a sense that they are per-thread and short lived. Consider it a 'reader' operation. They are however needed when you use unowned data (see the example in documentation). - Atomic storage (pointers): Shared storage (i.e. normal memory accessed by atomic operations). However they can be accessed only by the HazardPointer operations. Best regards [1] What HP is: http://en.wikipedia.org/wiki/Hazard_pointer signature.asc Description: This is a digitally signed message part ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala friendly atomic pointer
Thank you for the clarification and the link on HazardPointer. Nice day Nor Jaidi Tuah PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we do not accept liability for any viruses which may be transmitted in or with this message. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala friendly atomic pointer
http://www.valadoc.org/#!api=gobject-2.0/GLib.WeakRef
This is a simple solution thanks to the good design of GObject.
Tal
From: norjaidi.t...@ubd.edu.bn
To: vala-list@gnome.org
Date: Thu, 19 Dec 2013 08:59:44 +0800
Subject: [Vala] vala friendly atomic pointer
Dear all,
I want to implement something like these:
* x = AtomicPointer.@get (ref atomicRef) // reader
* AtomicPointer.@set (ref atomicRef, newref) // writer
* return AtomicPointer.@get (ref atomicRef) // reader
but have the benefit of vala ref counting.
The best I can think of is:
* lock (atomicRef) { x = atomicRef; }
* lock (atomicRef) { atomicRef = newref; }
* lock (atomicRef) { return atomicRef; }
But lock is too course.
e.g., lock (atomicRef) {x = atomicRef;} will also lock
out other readers, whereas AtomicPointer.get won't.
I realise that the exclusive region is small.
But if you have a lot of readers, the effect
may be significant.
Any suggestions?
Nice day
Nor Jaidi Tuah
PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you
are neither the addressee (intended recipient) nor an authorised recipient of
the addressee, and have received this message in error, please destroy this
message (including attachments) and notify the sender immediately. STRICT
PROHIBITION: This message, whether in part or in whole, should not be
reviewed, retained, copied, reused, disclosed, distributed or used for any
purpose whatsoever. Such unauthorised use may be unlawful and may contain
material protected by the Official Secrets Act (Cap 153) of the Laws of
Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei
Darussalam, accept[s] no responsibility for loss or damage arising from the
use of this message in any manner whatsoever. Our messages are checked for
viruses but we do not accept liability for any viruses which may be
transmitted in or with this message.
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
