Author Topic: DEFER statement  (Read 170 times)

psbrsneiman

  • Newbie
  • *
  • Posts: 7
    • View Profile
DEFER statement
« on: March 24, 2021, 09:59:47 AM »
In Go and V there is a DEFER statement

Used to free resources at end of SUB or FUNCTION, but keep it together with the relevant statements

Like
DIM aaa$ * 1000000000
DEFER FREE aaa$

I think this shouldn't be hard to implement

We could collect in an Array all those lines, and dump it on encounter of END/EXIT SUB/FUNCTION

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 786
    • View Profile
Re: DEFER statement
« Reply #1 on: March 24, 2021, 10:54:09 AM »
Hello Pinchas and welcome to the BCX club.

I have no experience with the languages GO or V but in GO, it looks like DEFER is used to support GO's concurrency model.
I admit, I may be wrong about that.  In any case, BCX does not support concurrency.


In BCX, a function like the following, gets its dynamically allocated memory released at the point(s) of function exit.


FUNCTION foo
DIM aaa$ * 1000000000
FUNCTION = 1                 ' Notice we do not need to FREE aaa$
end function



int foo (void)
{
  char *aaa;
  aaa=(char*)calloc(1000000000 ,1);
  if (aaa) { free(aaa);aaa = NULL; }          // BCX emits the release code automatically.
  return 1;
}
« Last Edit: March 24, 2021, 11:15:42 AM by MrBcx »

psbrsneiman

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: DEFER statement
« Reply #2 on: March 24, 2021, 08:47:26 PM »
Great work.

I was afraid about strings, because of the FREE statement help page, I see that's only relevant for global scope, or raw variables.

So it might only be needed for closing resources like files.

Could be that defer was invented for the Go concurrency, but i was using it as a global tool to close files, databases, etc.



Robert

  • Hero Member
  • *****
  • Posts: 601
    • View Profile
Re: DEFER statement
« Reply #3 on: March 26, 2021, 05:15:01 AM »
Hello Pinchas and welcome to the BCX club.
<snipt>
 In any case, BCX does not support concurrency.
<snipt>

I just re-listened to Rob Pike's lecture on Concurrency and I think BCX_THREAD and family are well within Pike's define of Concurrency. Here's an example to check the fit into the Concurrency paradigm. Concurrency is not parallelism.

Code: [Select]
'***************************************************************
 '              Begin Sample BCX_THREAD Application           
 '***************************************************************
 
 DIM hThread[3] AS HANDLE

 hThread[0] = BCX_THREAD(SUB1)
 hThread[1] = BCX_THREAD(SUB2)
 hThread[2] = BCX_THREAD(SUB3)

 SLEEP(2000) : COLOR 4,0 : PRINT " SUB3: Suspending"
 BCX_THREADSUSPEND(hThread[2])
 SLEEP(10000) : COLOR 4,0 : PRINT " SUB3: Resuming "
 SLEEP(2000)

 BCX_THREADRESUME(hThread[2])

 SLEEP(4000) : COLOR 4,0 : PRINT " SUB3: Cancelled!"

 BCX_THREADKILL(hThread[2])

 FOR INTEGER i = 0 TO 2
    BCX_THREADWAIT(hThread[i])
 NEXT

 COLOR 15,0

 PRINT "Press Any Key To END"

 KEYPRESS

 SUB SUB1
 DIM I
 FOR I = 1 TO 50
    COLOR 2,0
    PRINT " SUB #1 = ";I;
    SLEEP(500)
 NEXT
 COLOR 2,0
 PRINT " " : PRINT " SUB #1 Completed!"
 BCX_THREADEND
 END SUB

 SUB SUB2
 DIM I
 FOR I = 1 TO 50
    COLOR 3,0
    PRINT " SUB #2 = ";I;
    SLEEP(400)
 NEXT
 COLOR 3,0
 PRINT " " : PRINT " SUB #2 Completed!"
 BCX_THREADEND
 END SUB

 SUB SUB3
 DIM I
 FOR I = 1 TO 50
    COLOR 4,0
    PRINT " SUB #3 = ";I
    SLEEP(300)
 NEXT
 COLOR 4,0
 PRINT " " : PRINT " SUB #3 Completed!"
 BCX_THREADEND
 END SUB


see the attached .png for the output.

Robert

  • Hero Member
  • *****
  • Posts: 601
    • View Profile
Re: DEFER statement
« Reply #4 on: March 26, 2021, 05:22:06 AM »
Also, BCX_THREADWAIT is doing essentially the same job as Go's DEFER.

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 786
    • View Profile
Re: DEFER statement
« Reply #5 on: March 26, 2021, 09:21:24 AM »

I just re-listened to Rob Pike's lecture on Concurrency and I think BCX_THREAD and family are well within Pike's define of Concurrency. Here's an example to check the fit into the Concurrency paradigm. Concurrency is not parallelism.
 

Fascinating stuff ...

Below is a link to Rob Pike's lecture and the second link is to the paper by Tony Hoare that Rob recommends in his lecture.

https://talks.golang.org/2012/waza.slide#2

https://ora.ox.ac.uk/objects/uuid:e0143106-e414-4f02-bd3d-3f3f8db34e88/download_file?safe_filename=H77%252520-%252520Communicating.pdf&file_format=application%2Fpdf&type_of_work=General+item
« Last Edit: March 26, 2021, 10:09:52 AM by MrBcx »

psbrsneiman

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: DEFER statement
« Reply #6 on: April 09, 2021, 11:37:56 AM »
Just want to clear out  that DEFER doesn't mean to pause the process/thread/goroutine, it only means do this before END FUNCTION
The beauty is
1: it will run also on whatever pathway the routine will take, no need to close file in both if/else or in error handler
2: when the programmer writes open file, he knows immediately that it must be closed somewhere, so write it down rightaway, now you could begin thinking of reading writing to the handle.

Re concurrency threads and parallelism.
go routines is a subset of threads, and threads are weigh more powerful.
The only benefit of go routines is that it doesn't involve the OS, so is more lightweight and switching is easier, scheduling is done smarter, no impact on WMIC...
But in fact with threads can do the same, in terms of functionality.

Channels (for go routine communication) is a different feature , which could also be used with threads, and many c libraries are available to emulate, it so in fact that's also available in BCX https://github.com/tylertreat/chan

Mr Pike in his lecture want to answer another question, "concurrency" has a similar definition then "parallelism", the speech could also be called "threads is not parallelism", but that's too obvious, actually concurrency means threads, just a cheaper thread.

Multi threaded==Concurrent means, do it synchronously or parallel I do not care, if a race condition is an issue, then use Channels for communication.

Since BCX is grounded in C, for bcx to implement concurrency would mean, inserting long jumps, in some smart locations, those jumping between multiple call stacks and use channels to access shared variables, since channels are using a different operator <- its not too hard, but mostly I do not see an issue with using threads, and manual channels.

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 786
    • View Profile
Re: DEFER statement
« Reply #7 on: April 09, 2021, 01:14:49 PM »
Tyler's CHAN library should be easily usable from BCX, if anyone wants to experiment.

I want to spend more time examining Tyler's github repo - looks like he has a lot of fans.

The attached snapshot gave me a laugh - thankfully, I'm not on COMCAST!


MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 786
    • View Profile
Re: DEFER statement
« Reply #8 on: April 13, 2021, 06:26:25 PM »
Tyler's CHAN library should be easily usable from BCX, if anyone wants to experiment.

Seems I spoke too soon. 

Tyler's channel library depends on POSIX threads which might be fine on
some platforms but Windows apparently isn't one of them.

Wayne Halsdorf

  • Newbie
  • *
  • Posts: 15
    • View Profile

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 786
    • View Profile
Re: DEFER statement
« Reply #10 on: April 14, 2021, 10:41:56 AM »
Thanks Wayne ...

I already wasted enough time with this: https://sourceforge.net/projects/pthreads4w/

Getting something that might compile CHAN only in MSVS is not high on my list.

I personally have no need for pthreads, so I'll leave the heavy lifting to those who do.
« Last Edit: April 14, 2021, 05:38:43 PM by MrBcx »

MrBcx

  • Administrator
  • Hero Member
  • *****
  • Posts: 786
    • View Profile
Re: DEFER statement
« Reply #11 on: April 14, 2021, 11:10:06 AM »
 ... and whenever I do need threads in a BCX project, we already have these:

https://bcxbasiccoders.com/webhelp/html/bcx_threadprocedures.htm
« Last Edit: April 14, 2021, 05:39:28 PM by MrBcx »