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
Attachment:
signature.asc
Description: This is a digitally signed message part