8 replies to this topic

[Nick]

Hi all,

I'm looking for an appropriate word. :lol: I'm designing a generic 'resource' class that can be in three different access modes. The first is shared access, which means multiple 'clients' can access it simultaneously, and typically it means that they will only be reading from the resource. Exclusive access means only one client has access, typically for writing to the resource. Up to this point it corresponds with a normal multiple-reader/single-writer lock, or more correctly a shared/exclusive lock (since nothing prevents a client from writing to a shared resource if it knows that it won't overwrite any data the other clients are reading or if those clients don't mind).

The tricky bit is the third mode, for which I have no name yet. It assumes that the resource is split into pieces and multiple clients can each have exclusive access to a piece, without further defining how it's split up. Clients simply have to play nice through some external mechanism that assigns clients to the pieces (e.g. a concrete matrix class derived from the resource class that keeps track of the rows/columns/elements assigned to specific clients). The point is that the resource class itself should remain lightweight, and I believe this approach could be faster than having an ordinary shared/exclusive lock on each piece individually.

Anyway, long story short, I'm looking for a name for the third access mode. I've considered "Mutual", "Cooperative" and "Partitioned", but with English not being my first language I feel like I'm missing the ultimate one-word description of my third access mode. So any and all suggestions are greatly appreciated. :worthy:

Thanks,

Nick

[phresnel]

Foobar sounds nice :) The other three, too :D

Just to add one more: How about chunked?

*ducks + runs away*

[.oisyn]

Split?

[Kenneth Gorking]

Pieced?
Restricted?
Partial?

[SmokingRope]

Chunk Limited

it's not a single word but you could always get rid of the space :lol:

Also for any who have not tried this wonder of internet technology, try doing a search for "reverse dictionary".

[alphadog]

The difficulty come because the first two access modes describe that access to one resource: shared vs. exclusive. However, the third mode describes the coordination of access to multiple resources.

So, names could be coordinated? Or, managed? Unified?

BTW, without knowing your code better, I wonder if there's a small whiff of "code smell" there...

Consider a redesign; split your classes into classes that lock on a share/exclusive, and another higher-level class that manages the coordination of that state across multiple resources...

[kusma]

How about "Segmented"?

[Nautilus]

"Semaphored" ?

I get the idea the 'clients' are multiple cores shooting for a common goal.

Ciao ciao : )

[Nick]

Thanks a lot for all the suggestions!

SmokingRope said:

Also for any who have not tried this wonder of internet technology, try doing a search for "reverse dictionary".

That's interesting. :yes: It came up with the word "private", which captures the meaning quite nicely. Like at a private party where multiple people are invited but it's not open for everyone either.

Quote

The difficulty come because the first two access modes describe that access to one resource: shared vs. exclusive. However, the third mode describes the coordination of access to multiple resources.

So, names could be coordinated? Or, managed? Unified?

I'd like to keep the name as abstract as possible. Having a resource that is split into pieces/segments/chunks is an easy way of thinking about it and a likely concrete implementation, but not the only one. I like the name "managed".

Quote

Consider a redesign; split your classes into classes that lock on a share/exclusive, and another higher-level class that manages the coordination of that state across multiple resources...

That's definitely one way to implement this mode. But it can actually be more efficient when keeping it low-level instead of composing it out of several layers. Anyway, it's just some experimental code I'm working on so I'm not even sure what direction to take yet.

Quote

I get the idea the 'clients' are multiple cores shooting for a common goal.

They could be cores, SMT threads, multitasking threads, processes, entire chips, whole systems, network nodes, etc. The rough idea is to create a universal specification for processing data having multiple 'clients' and multple 'servers'.