Ok, I got a Real Blog cooking up but I want to see the new system work so people can comment.
The RSS feed should work.
Comments should work.
Please can I get a few comments from readers so I know the blog is functional?
When I see it working I’ll can this blog post and put up some Real Stuff.
Thanks,
Cliff
Testing the functions
Here’s my test!
Testing testing 123
Hoping this works!
Works for me!
Thanks for getting an RSS feed working!
a comment test
Hello.
i think we are ready for the new blog post
working for me …
Previously I was able to read
Previously I was able to read the whole post in Google Reader.
Now there is just a short fragment (first two lines). Kind of annoying but not critical
Full feed in Google Reader
+1 for a full feed in Google Reader. Doing two clicks isn’t the end of the world, but the old system was nicer.
still looks broken in Google
still looks broken in Google Reader: wrong title (“Generated feed for “http://www.azulsystems.com/blogs”") and just a snippet: “April 29th, 2010. Testing the New Blog Setup. Ok, I got a Real Blog cooking up but I want to see the new system work so people can comment. The RSS feed…” (it ends with those dots).
Testing
One of my favourite blogs!
Comments on old posts broken
Hi,
comments are disabled for all posts migrated from the old blog, say this:
http://www.azulsystems.com/blog/cliff-click/2008-11-13-some-source-forge-threads-nbhm
or even this:
http://www.azulsystems.com/blog/cliff-click/2010-04-17-odds-n-ends-2
What I’d like to say, about those posts, is that you seem to have missed a point about the C++ memory model. Benign races can be used, if you use low-level “atomic” variables and a special access API. The best argument for this is the documentation value this adds to the source, since the effort to code a benign data race is anyway big and _will_ be documented in the source somewhere.
Odds and ends 2 – atomic refcounts
[I'm commenting here because comments there are closed - sorry].
From http://www.azulsystems.com/blog/cliff-click/2010-04-17-odds-n-ends-2:
“Why is ref-counting hard to use in managing concurrent structures?”
The usual mistake is to put the count in the structure being managed. The failing scenario is where one thread gets a pointer to the ref-counted structure at about the same time as the last owner is lowering the count and thus preparing to delete. Timeline: T1 gets a ptr to the ref-counted structure. T2 has the last read-lock on the structure and is done with it. T2 lowers the count to zero (T1 still holds a ptr to the structure but is stalled in the OS). T2 frees the structure (T1s pointer is now stale). Some other thread calls malloc and gets the just-freed memory holding the structure. T1 wakes up and increments where the ref-count used to be (but is now in some other threads memory).
You mean non blocking structures instead of concurrent ones, right?
Since I’ve seen all sort of reasonable users doing that (including the Linux kernel, and all refcount-based GC’s), there’s something strange. Indeed, I’d expect that if T2 is using the structure S and it is reachable by other threads through a pointer, the refcount is 2 (one for T2, one for the pointer); T2 decs the counter, atomically {clears the globally reachable pointer & decs the counter again}, and it’s done. I think you mean that _without locks_ you can’t do it, right?
It’s maybe interesting to think about the possibility of refcount GC’s (like the experimental one for CPython, around the 1.5 times). For a GC the refcount must be inside the object (where else? You need a ‘main’ reference to do otherwise). Does it mean that clearing a reference must be atomic with the corresponding refcount decrease? That’s… ouch… slower than ever!
(Yes, I agree that refcount GC is stupid, but CPython is stuck with that).