Re: URCU use cases

Re: URCU use cases

[Michel Dagenais]

[-- Attachment #1.1: Type: text/plain, Size: 702 bytes --]

> Studying the API of URCU it seems that it's mostly intended for
> link-based data structures, such a lists. Suppose I have a large
> struct that is often accessed by many readers, and some writers that
> occasionally update few fields each time. If I understand correctly,
> using URCU, the writers would have to make a copy of the struct on
> each write, make the changes, and then publish the updated version.
> This is wasteful for small updates to a large struct.
RCU / URCU is efficient for read-mostly structures. In that case, copying a large struct may not be such a problem since it is infrequent. You also have the option of splitting the structure into smaller independently updated ones. 

[-- Attachment #1.2: Type: text/html, Size: 1614 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: URCU use cases

[Ilya Mirsky]

[-- Attachment #1.1: Type: text/plain, Size: 1097 bytes --]

That's what I thought, thanks for confirming my understanding.
I still miss something about URCU's implementation.
How would a code that operates on multiple structures look like,
as all the api functions are context free (read_lock(), rcu_synchronize(),
etc. have no parameters)?

Thanks,
Ilya

On Sat, Sep 6, 2014 at 4:18 PM, Michel Dagenais <michel.dagenais@polymtl.ca>
wrote:

> Studying the API of URCU it seems that it's mostly intended for link-based
> data structures, such a lists. Suppose I have a large struct that is often
> accessed by many readers, and some writers that occasionally update few
> fields each time. If I understand correctly, using URCU, the writers would
> have to make a copy of the struct on each write, make the changes, and then
> publish the updated version. This is wasteful for small updates to a large
> struct.
>
> RCU / URCU is efficient for read-mostly structures. In that case, copying
> a large struct may not be such a problem since it is infrequent. You also
> have the option of splitting the structure into smaller independently
> updated ones.
>
>

[-- Attachment #1.2: Type: text/html, Size: 2428 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

URCU use cases

[Ilya Mirsky]

[-- Attachment #1.1: Type: text/plain, Size: 542 bytes --]

Hi,

Studying the API of URCU it seems that it's mostly intended for link-based
data structures, such a lists. Suppose I have a large struct that is often
accessed by many readers, and some writers that occasionally update few
fields each time. If I understand correctly, using URCU, the writers would
have to make a copy of the struct on each write, make the changes, and then
publish the updated version. This is wasteful for small updates to a large
struct.

Am I missing something here? Is there a better way of doing this?

Thanks,
Ilya

[-- Attachment #1.2: Type: text/html, Size: 650 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev