Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] crossbeam-epoch tagging for enum-like struct #342

Open
alanhdu opened this issue Mar 12, 2019 · 2 comments
Open

[Feature Request] crossbeam-epoch tagging for enum-like struct #342

alanhdu opened this issue Mar 12, 2019 · 2 comments

Comments

@alanhdu
Copy link

alanhdu commented Mar 12, 2019

Right now, crossbeam_epoch::Atomic offers a tagging facility, which lets you use the lower bits of the pointer to implement arbitrary tagging. This is a pretty nice facility, but I'm having a little trouble figuring out how to use it effectively!

In my use case, I have essentially 4 different structs of different sizes. I'd like to have a single type T such that crossbeam_epoch::Atomic<T> acts something like enum { S1(Atomic<S1>), S2(Atomic<S2>), S3(Atomic<S3>), S4(Atomic<S4>) }, using the tag of crossbeam_epoch::Atomic to store the enum variant. But this would mean that when Crossbeam garbage collects T, the actual amount of memory it needs to free depends on the tag (because the structs are sized differently), and I don't know how to represent that to Crossbeam!

(The actual use case shows up in an ART data structure (a fancy trie), which has a common Node * that is either an interior node or a leaf node depending on the last bit of the pointer). I could probably move the tag into type T instead of in the Atomic pointer for a little extra space, but I'd like to match the original C++ implementation as much as possible.

@alanhdu alanhdu changed the title [Feature Request] crossbeam-epoch tagging for enum-like box [Feature Request] crossbeam-epoch tagging for enum-like struct Mar 12, 2019
@ghost
Copy link

ghost commented Apr 22, 2019

I'm afraid there is no pretty way of doing this - you should probably use AtomicUsize to represent these tagged pointers manually.

@jeehoonkang
Copy link
Contributor

Here is a related PR, which adds the support for DST: #209 The Storage trait gives you an ability to specify the size of the underlying data.

(@alanhdu Actually, I'm also implementing a concurrent ART, and proposed the PR to solve the same problem you have :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants